Technical accessibility examples - ARIA, visually-hidden, tab-index etc

Questions
#1

A few months ago I contributed to a blog post of web accessibility examples that I thought some of you might find useful. The sections for BBC and GOV.UK contain some advanced screen reader tricks and ARIA markup, with screenshots to illustrate how each solution works:
Inviqa Blog - Web accessibility examples: 5 sites doing it right

Does anyone else know of any other sites that have good examples of different technical accessibility solutions? For example:

  • Well-implemented ARIA techniques (where vanilla HTML and CSS don’t quite cut it)
  • CSS hacks like visually-hidden/screen-reader-only classes to provide alternative/additional information to screen reader users.
  • Good use of the tabindex attribute to improve keyboard navigation.

Also, if anyone has any examples (from their own site or someone else’s) that they’re not sure about, you could post them here for others to test!

2 Likes
#2

I have to ask 2 questions at this juncture.

  1. ARIA is/or is not intended for hand written markup and pages? Basically, which easy to get hold of editors currently exist?

  2. Do we have any metrics or data to show that it is making a difference to users experience? I am seeing emphasis on users with no mouse that will use TAB to navigate, which is frankly UX 101 territory if you fail. What about users with no keyboard at all, or is there a body of data showing that disabled users always do have a keyboard, and if so what keys will it have? I suppose I’m getting at the question the charity website devs could probably answer.

Good to see more standardisation - has anyone gotten any good static testing tooling or approaches built? I’m assuming a lot of DOM exploring and checking that ARIA tags match the “visually clued” tags and CSS, would that be a fair way to statically rate quality?

1 Like
#3

Interesting questions. My take on each:

  1. No, I wouldn’t expect ARIA to be used for actual content, mainly because it shouldn’t be necessary 99% of the time (as long as your WYSIWYG editor spits out valid HTML and provides access to a wide range of elements), but also because making these attributes available to content editors who don’t fully understand them would likely do more harm than good. In my experience, ARIA is useful for ensuring that ‘page furniture‘ (header, footer, sidebars, carousels, tabbed interfaces) are more compatible with assistive technology. These page components generally aren’t accessible to content editors (although editors might have control over their content), so ARIA can be used to provide a consistent, ‘bullet-proof’ experience to assistive technology users. Saying that, there’s a few situations where ARIA (or similar) attributes could be added under the hood based on content editor action; for example a WYSIWYG editor could offer a ‘Hide from screen readers’ option to allow content editors to add a repeated/redundant link/button to their content without creating unnecessary annoyances for screen reader users.
  2. It’s clear that not all assistive technology supports the ARIA spec in full, but ARIA is part of the finalised HTML 5 spec and there is at least some level of support in current versions of assistive technology. I would argue that there’s no harm in using these attributes as long as a) they’re used correctly, b) they add value - not just used instead of ‘vanilla’ HTML alternatives, and c) you’re not relying upon ARIA for the core functionality of your site. Some of the the GOV.UK examples in my post demonstrate ARIA attributes working well with macOS VoiceOver, but your mileage may vary with other screen reader + browser combinations. With regards to keyboard accessibility, it’s often the case that ‘keyboard’ is used as shorthand for ‘keyboards and other alternative input devices’, as it’s assumed that many alternative input devices will emulate keyboard behaviour, with specific buttons configured to specific keyboard keys/combinations.

It’s very difficult to properly test ARIA without access to a representative assistive technology, but tools like WAVE will highlight when ARIA properties are used so you can investigate whether the chosen approach is valid/helpful. Tools like pa11y will also flag up ARIA attributes that don’t actually exist or have been used on the wrong type of element.

1 Like
#4

@rightsaidjames said “
 tools like WAVE will highlight when ARIA properties are used so you can investigate whether the chosen approach is valid/helpful.”

Certainly this is the approach that I’m tending towards. Our browser-based application is a specialist administrative tool rather than a public-facing site, so beyond avoiding some of the more obvious presentational errors and thinking about navigational issues, I’m tending towards thinking that we won’t be able to make our product fully compatible with WCAG guidelines until we are presented with a situation where a user has a requirement to use a specific assistive technology. (Our client and user base is sufficiently small for us to take this approach.)

We are migrating to a Cloud-based hosting solution where we intend offering hosting to our clients as an alternative to their installing our product on their servers. This in turn has implications for taking on the responsibility for deployment, implementation and configuration, My view is that we shall have to start working more closely with clients on accessibility issues under a hosted arrangement, and that will mean our being able to configure our application to work with whatever assistive technology we are presented with. And of course, this means being able to cope with requirements to adopt an assistive technology as circumstances demand, such as a key member of the client’s team acquiring a new accessibility need through accident or illness.

Of course, this does mean building in the appropriate code structures early to keep bespoke configuration work to a minimum. As the product has already been under development for some time, this presents its own challenges; but a journey of a thousand miles begins with a single step.

2 Likes