Web accessibility is not optional—it is a fundamental requirement for building inclusive digital products. The Web Content Accessibility Guidelines (WCAG) 2.2, published by the W3C, introduce new success criteria that address the needs of users with cognitive and motor disabilities. At Nexis Limited, we integrate accessibility into every stage of the development lifecycle, ensuring our products are usable by everyone.
Understanding WCAG 2.2
WCAG 2.2 builds upon its predecessors with nine new success criteria. Key additions include Focus Not Obscured, which ensures that focused elements are not hidden behind sticky headers or modals. Dragging Movements requires that any functionality using drag interactions also offers a single-pointer alternative. Target Size establishes a minimum interactive area of 24x24 CSS pixels for touch and pointer targets. These criteria reflect the reality that modern web interfaces must accommodate diverse interaction methods.
Semantic HTML as the Foundation
Proper semantic HTML is the most impactful accessibility improvement a developer can make. Using native elements like button, nav, main, article, and form provides built-in accessibility behaviors that custom divs and spans do not. Screen readers rely on the document's semantic structure to convey meaning. A heading hierarchy using h1 through h6 allows users to navigate content efficiently, while landmark regions help them jump between major sections of the page.
ARIA When Native Semantics Fall Short
ARIA attributes should supplement, not replace, native HTML semantics. Use role attributes to define the purpose of custom widgets. The aria-label and aria-describedby attributes provide additional context when visual cues alone are insufficient. For dynamic content, aria-live regions notify assistive technologies of updates without requiring the user to navigate to the changed area. However, overusing ARIA often introduces more problems than it solves—always prefer native elements first.
Keyboard Navigation
Every interactive element must be operable via keyboard. This includes managing focus order with tabindex, implementing keyboard shortcuts for custom widgets, and trapping focus within modal dialogs. The roving tabindex pattern is essential for composite widgets like toolbars and tab panels, where only one item in the group should be in the tab order at a time while arrow keys move focus within the group.
Color and Contrast
WCAG 2.2 maintains the requirement of a 4.5:1 contrast ratio for normal text and 3:1 for large text. We use automated tools like axe-core and Lighthouse to verify contrast compliance during development. Color should never be the sole means of conveying information—always pair it with text labels, icons, or patterns to accommodate users with color vision deficiencies.
Automated and Manual Testing
Automated tools catch approximately 30-40% of accessibility issues. We integrate axe-core into our CI/CD pipelines using jest-axe for unit tests and Cypress or Playwright with accessibility plugins for end-to-end tests. However, manual testing with screen readers like NVDA and VoiceOver remains essential for catching issues that automated tools miss, such as illogical reading order or confusing interaction patterns.
Accessibility is an ongoing commitment, not a one-time checklist. Contact us to learn how we embed accessibility into development workflows. Explore our portfolio to see accessible products we have built for clients in healthcare, education, and government sectors.