P
Perceivable
Present information in ways that can be perceived through text, visual, auditory, or assistive-technology alternatives appropriate to the content.
Digital Accessibility
Accessibility designed into the operating experience.
Rege-IT Solutions is committed to making its website and digital content usable by people with disabilities. Accessibility is considered across information structure, keyboard interaction, visual presentation, responsive behavior, content alternatives, and support processes.
AA
WCAG 2.2 Level AA is the current design and evaluation target.
Rege-IT does not represent that every page, document, integration, or third-party component fully conforms until the relevant scope has been evaluated and any identified barriers have been addressed. This statement describes the present commitment, target, review process, and known accessibility boundaries.
Accessibility Principles
Design content and interaction so more people can use them independently.
The accessibility approach follows four operating principles: information should be perceivable, controls should be operable, content should be understandable, and the implementation should be robust across compatible technologies.
O
Operable
Support keyboard access, visible focus, sufficient target sizing, predictable controls, and alternatives to interactions that depend on a single input method.
U
Understandable
Use consistent navigation, descriptive headings, meaningful link text, clear instructions, and language appropriate to the intended enterprise audience.
R
Robust
Use semantic HTML and programmatically determinable names, roles, states, and relationships so content can work with supported browsers and assistive technologies.
Current Accessibility Support
Design controls mapped to practical user needs.
The following areas describe the intended behavior of the current public website. They should be validated whenever navigation, content, components, or visual styling materially change.
Area
Current Approach
Ongoing Review
Page Structure
Semantic organization and landmarks
Pages use headings, main content, navigation, sections, articles, footers, and descriptive page titles to support orientation and reading order.
- Heading sequence and landmark review
- Descriptive title and metadata checks
- Reading-order verification
- Duplicate landmark and label review
Keyboard Access
Core navigation without pointer dependence
Links and controls are intended to be reachable and operable by keyboard, with visible focus indicators and a skip link to bypass repeated navigation.
- Logical tab sequence
- Visible focus-state review
- Menu open, close, and Escape behavior
- Keyboard trap testing
Visual Presentation
Legible typography and adaptable layout
Content uses scalable text, responsive layouts, restrained animation, persistent focus, and color systems intended to maintain readable contrast and hierarchy.
- Text and non-text contrast review
- Zoom and text-resize testing
- Small-screen reflow validation
- Color-independent meaning checks
Motion and Timing
Reduced distraction and user control
The public pages avoid essential auto-playing motion and honor reduced-motion preferences by minimizing or removing non-essential animation and transition effects.
- Reduced-motion preference validation
- Auto-updating content review
- Pause, stop, and hide controls where needed
- Timeout and session-warning review
Non-Text Content
Alternatives matched to content purpose
Informative images should include useful text alternatives. Decorative visuals should be ignored by assistive technology. Complex diagrams require an equivalent text explanation or structured data view.
- Alternative-text quality review
- Decorative-image handling
- Diagram and workflow descriptions
- Caption and transcript checks for media
Forms and Controls
Programmatic names and clear instructions
Interactive controls should expose accessible names, roles, values, states, instructions, validation feedback, and error-recovery information.
- Label and instruction review
- Error identification and focus handling
- Status-message announcements
- Target-size and interaction testing
Standard and Conformance Position
WCAG 2.2 Level AA guides the accessibility program.
WCAG provides testable accessibility criteria for web content. Rege-IT uses Level AA as the current target for new public pages and material changes, while documenting limitations and remediation work rather than making unsupported conformance claims.
WCAG 2.2 Level AA
New public content and components should be designed, implemented, and reviewed against applicable Level A and Level AA criteria.
Representative manual and automated review
Assessment should cover representative pages, common templates, navigation paths, interactive components, responsive states, and relevant content formats.
Conformance not yet formally certified
Unless Rege-IT publishes a dated and scoped conformance report, this statement should not be interpreted as independent certification or a claim that every item fully conforms.
REV
Accessibility status is reviewed as the site evolves.
A full-conformance statement requires evaluation of the defined scope and resolution of all applicable Level A and Level AA failures. Partial implementation, selected techniques, or automated scanning alone are not represented as full conformance.
Accessibility Review Lifecycle
Accessibility validation continues from design through production change.
Automated checks can identify certain issues, but meaningful accessibility review also requires keyboard testing, visual inspection, content review, and assistive-technology evaluation.
-
Stage 01
Design Review
Evaluate hierarchy, contrast, responsive behavior, focus treatment, target size, motion, and interaction patterns before implementation.
-
Stage 02
Semantic Build Review
Confirm landmarks, headings, labels, names, roles, states, relationships, alternative text, and source order.
-
Stage 03
Automated Evaluation
Use automated tools to detect selected contrast, labeling, structure, parsing, and component issues requiring review.
-
Stage 04
Manual Interaction Testing
Test keyboard operation, zoom, text resizing, reflow, focus order, error handling, and reduced-motion behavior.
-
Stage 05
Remediation and Monitoring
Prioritize barriers, document corrections, retest affected flows, track exceptions, and review material changes after release.
Assistive-technology testing should use a documented combination of representative browsers, operating systems, screen readers, magnification, voice input, and keyboard-only workflows appropriate to the deployed experience.
Technical Compatibility
Standards-based implementation across supported technologies.
The public website is built with HTML, CSS, and limited JavaScript and is intended to work with current, standards-supporting browsers and assistive technologies. Compatibility may vary with browser version, operating system, assistive-technology configuration, extensions, security settings, and third-party content.
Current standards-supporting browser versions
Rege-IT prioritizes current versions of major desktop and mobile browsers. Unsupported, obsolete, or heavily modified browsers may not receive the same accessibility behavior.
Semantic compatibility over device-specific assumptions
Components should expose information through standard HTML and accessible platform APIs. A formal compatibility matrix should be published only after representative combinations have been tested.
Content reflow across screen sizes and zoom levels
Layouts are intended to adapt without requiring horizontal scrolling for ordinary text content, except where a two-dimensional presentation legitimately requires it.
Browser and operating-system settings remain respected
The site supports user-controlled text scaling and reduced-motion preferences and avoids overriding user-selected accessibility settings where practical.
Known and Potential Limitations
Accessibility boundaries are disclosed and addressed through review.
Some content or services may depend on systems outside Rege-IT’s direct control or may require additional alternatives. Reported barriers are evaluated based on impact, scope, available remediation, and the relationship between Rege-IT and the provider.
Third-Party Platforms
Links, embedded services, scheduling tools, authentication services, and connected enterprise platforms may have accessibility behavior governed by their respective providers.
Documents and Downloads
PDF files, exported reports, diagrams, spreadsheets, and archived materials may require separate accessibility remediation or an alternative HTML, text, or structured-data version.
Complex Architecture Visuals
Workflow diagrams and system maps may require adjacent text descriptions, ordered process steps, tabular equivalents, or downloadable accessible documentation.
Experimental or Pilot Features
Demonstration, pilot, beta, or rapidly changing components may not yet have completed the same accessibility review as stable public content.
Alternative access is available by request.
When a barrier cannot be corrected immediately, Rege-IT will seek a reasonable alternative method for providing the relevant public information or supporting the requested business interaction.
Accessibility Assurance
Evidence should support accessibility claims.
Accessibility review for a procurement or enterprise engagement should rely on scoped evidence rather than generic claims. Availability of specific materials depends on the product, deployment, contract, and assessment completed at the time of review.
Conformance Assessment Scope
Defined pages, components, user flows, technologies, environments, versions, standards, and assessment dates.
Accessibility Issue Register
Identified barriers, affected criteria, user impact, severity, ownership, remediation status, and retest evidence.
Design and Engineering Checklist
Repeatable requirements for structure, keyboard access, focus, contrast, labels, motion, alternatives, and component behavior.
Third-Party Dependency Inventory
Embedded or connected services, provider ownership, known limitations, available alternatives, and escalation paths.
Remediation and Exception Records
Corrective actions, risk acceptance, temporary alternatives, target dates, approvals, and closure verification.
Statement Version History
Publication date, scope changes, assessment updates, material limitations, and contact-process revisions.
Feedback and Assistance
Report barriers and request an alternative method of access.
Rege-IT welcomes accessibility feedback concerning the website, documents, diagrams, contact process, or other public digital content. The accessibility contact workflow is intended for barrier reporting, alternative-format requests, interaction assistance, and unresolved concerns. Reports should include enough detail to locate and reproduce the issue without including passwords, access tokens, medical details, regulated records, or unrelated confidential information.
Response target
Rege-IT aims to acknowledge accessibility feedback within five business days. Resolution time depends on severity, complexity, third-party involvement, and the availability of an effective alternative.
Report a Website Barrier
Include the page address, the task attempted, the barrier encountered, browser or device, assistive technology when relevant, and preferred contact method.
Request an Alternative Format
Request an accessible HTML, plain-text, structured-data, large-text, or other reasonable version of public information when the original format is not usable.
Request Interaction Assistance
Ask for support completing a public website task, scheduling an architecture review, locating information, or using an available alternative communication process.
Escalate an Unresolved Concern
Reference the earlier report and describe the remaining barrier or requested follow-up so the concern can be reviewed at the appropriate operational level.
Accessibility Contact
Help us identify and remove barriers to access.
Contact Rege-IT to report an accessibility issue, request an alternative format, or obtain assistance with public website information. The contact workflow adapts to accessibility inquiries and does not require enterprise qualification information that is unrelated to the reported barrier. Include the affected page or content, the task you were attempting, and the format or support that would be most useful. When the form cannot be used, the email address in the footer remains available as an alternative contact method.
- Identify the page or content
- Describe the barrier and task
- State the preferred alternative