Making sure your digital products and services are accessible is everyone’s responsibility, as my colleague Lara Nagle explains in her recent blog Accessibility: who owns it? And while often people immediately think about design and how something looks when they talk about accessibility, as a developer, I know firsthand how that’s just one aspect. In fact, how a site or app is built is intrinsically linked with whether or not your digital experience is inclusive.

I’ve now worked on numerous projects - public bodies had to ensure accessibility in 2020- and here’s what I have learned.

While there is no specific EAA standard, there are standards like the Web Content Accessibility Guidelines (WCAG) and  EN 301 549, the accessibility requirements for ICT products and services.

Currently, it is understood that if a site/app meets WCAG standards, then it will be EAA compliant.

WCAG standards are divided into four principles:

• Perceivable: Information and user interface components must be presented in ways users can perceive.
• Operable: User interface (UI)components and navigation must be operable.
• Understandable: Information and operation of the interface must be comprehensible.
• Robust: Content must be robust enough to be interpreted by a wide variety of user agents, including assistive technologies.

The WCAG standards continuously evolve, and at this time, we aim to meet WCAG 2.2 AA requirements for our clients.

Embed accessibility from within. Here’s what I prioritise:

• Semantic elements: Use semantic elements to help browsers and assistive technologies understand the role of each part of the page.
• Provide text alternatives: Ensure all meaningful, non-decorative images and icons have descriptive text, whether through alt attributes, visually hidden text, or figcaptions for complex graphics and charts.
• Accessible forms:
  • Label inputs clearly using <label> tags and for attributes.
  • Use the aria-describedby attribute to provide additional guidance to form fields and error messaging.
  • Group related inputs with <fieldset> and <legend> to provide context and make it easier for the user to comprehend the structure of the form.

For more information on this, here’s the link to the Semantic HTML Structure  

WCAG Guideline 1.3.1

Accessible Rich Internet Applications (ARIA) can be used to enhance semantic HTML, providing better support for browsers and assistive technologies.

• Use native HTML elements first: Prefer semantic HTML (<nav>, <main>, <button>, etc.) over ARIA roles when possible — they're more widely supported and less error-prone.
• Only use ARIA when necessary: ARIA should enhance accessibility, not replace the correct HTML structure.
• Use appropriate ARIA roles: Examples: role= "dialog" for modals, role= "alert" for live error messages.
• States and Properties: Use attributes like aria-expanded, aria-hidden, and aria-live to inform assistive technologies about dynamic content.
• Testing: Use screen readers to navigate the page to understand how ARIA content is announced to the user and ensure it makes as much sense as the visual experience.

Here's a link to the Use ARIA attributes correctly

WCAG Guideline 4.1.2

Poor colour contrast is one of the most common mistakes on websites.

To avoid this issue, remember:

Contrast Ratios: WCAG requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text. Use tools like WebAIM: Contrast Checker to validate your designs.

• Avoid colour alone: Don’t rely on colour to convey information. Use text labels, patterns, size, or shapes to supplement colour distinctions.
• Dark mode support: Ensure your designs remain accessible in dark mode by maintaining contrast and readability.

Because so many people use a mouse, this tends to get overlooked. 

 Ensure your application can be fully navigated solely using a keyboard:

• Focus Management:
  • Use tabindex where necessary to maintain a logical focus order.
  • Avoid skipping interactive elements like buttons or links.
  • Ensure focus styles are clearly understood.
• Semantic HTML: Using native HTML elements grants default keyboard behaviour compared to custom elements, which require additional work to behave as the user expects.
• Skip Links: Provide a "skip to content" link for screen reader and keyboard users.
• Update States: use ARIA to update the state of elements, such as buttons and tabs, so the user can clearly understand the current state of the page.

Testing: Test navigating the page using the keyboard alone to confirm the user can access information as easily as a mouse and keyboard user.

Of course, one of the key aspects of accessibility is remembering that some people will be using assistive technologies like screen readers, voice recognition software, reading assistants, and switch devices that replace the need to use a keyboard or mouse.

So make sure that they work.

• Screen Readers: Test with popular screen readers like NVDA, JAWS, or VoiceOver.
• Browser Accessibility Tools: Leverage built-in tools like Chrome’s Lighthouse or Firefox Accessibility Inspector.
• Automated Testing: Tools like axe, Pa11y, and WAVE can catch common accessibility violations but should complement—not replace—manual testing.
• User Testing: Whenever possible, include users with disabilities in your testing process for genuine feedback.

Here’s the link to the Assistive Technology Compatibility 
WCAG Guideline 4.1.2

Modern applications often rely on JavaScript for interactivity, but dynamic content can introduce accessibility challenges.

• Announcements: Use aria-live regions to announce dynamic updates to screen readers.
• Focus Handling: Move focus programmatically to modals, alerts, or other dynamic elements and restore focus when the user closes these elements. Also, trap focus where necessary until the element is closed.

Progress Indicators: Ensure that loading states and progress indicators are accessible.

Accessibility is not a one-time task. Embed it into your development workflow:

• Integrate accessibility into CI/CD Pipelines: Use tools like axe-core CLI to catch issues during the build process.
• Training and education: Stay updated on evolving accessibility standards and best practices.
• Documentation: Maintain clear documentation of your accessibility practices and guidelines for team members.

Remember, accessibility is a journey, not a destination. By embedding accessibility into our code, design, and workflows, we build experiences that benefit all users—because the web is for everyone.