[FAQ]

Hi all,

I’m a developer working on a fairly complex web application, not just a simple website. We have a lot of interactive components like custom drop-down menus, date pickers, and modal windows.

I’ve been tasked with leading the effort to make our app more accessible (A11y), but my experience so far has mostly been with static sites (e.g., making sure images have alt text). This feels like a much bigger challenge.

Where do I even start? My main concerns are ensuring all our custom components are usable by people who can’t use a mouse, and making sure all the dynamic content (like error messages or new data loading) is properly announced by screen readers.

I’m looking for the key considerations to focus on that will make the biggest impact for a web application specifically.

Thanks.

[Jeff Bullas]

This is a critical topic, as application accessibility goes well beyond static content.

Short Answer: For a web application, your key considerations are ensuring all functionality is operable via a keyboard, using correct semantic text in your code, and using ARIA attributes to describe the state of your dynamic components to screen readers.

It’s about making your interactive elements perceivable and operable for every type of user, not just those using a mouse.

For a complex application, your focus must be on interaction and dynamic content. First, you must prioritise keyboard navigation; every single action, from opening a video player to submitting a form or navigating a custom menu, must be achievable using only the tab, arrow, and enter keys. This includes ensuring there is always a visible focus indicator and that users never get trapped in a component. Second, you must use semantic HTML text as your foundation, for example by using the button element for buttons and the nav element for navigation, as assistive technologies understand these native text elements perfectly. Finally, for your custom-built components, you must use ARIA, or Accessible Rich Internet Applications; these are extra text tags in your code that explicitly tell a screen reader what an element is, such as a role of ‘dialog’, and what its current state is, such as an aria-expanded state of ‘true’, which is essential for making dynamic content understandable.

Cheers,
Jeff

[Author]

Posts