CODEWITHSUNDEEP
javascripthtmlcssaccessibilitywai-aria
Michael
Michael

Reputation: 1833

Hide irrelevant focusable elements from screen reader

I have an element on page my which overflows horizontally and uses overflow: auto to allow content to be scrolled into view. All the content is rendered on load (i.e. it is always present in the DOM, not rendered when scrolled into view).

There are also two custom buttons on the page which use JavaScript to scroll this element to the left and right.

I need the buttons to be clickable for mouse users and focusable for keyboard users. But for screen reader users these buttons really serve no purpose because the fact that the element scrolls is irrelevant to a screen reader which will announce all of the content anyway.

I tried putting aria-hidden on the buttons container but this fails the accessibility rule aria-hidden-focus (see https://accessibilityinsights.io/info-examples/web/aria-hidden-focus/) because the buttons remain focusable.

I am aiming to achieve the best experience for all users which for screen readers means hiding the buttons which serve no purpose. But I can't work out a way to do this without using JavaScript to try and detect screen readers which seems a bit gross and error prone.

Is there a way this can be solved whilst providing a good experience all round?

Upvotes: 2

Views: 4423

Answers (2)

Andy
Andy

Reputation: 6170

I believe clearing up one common misconception will render the solution very clear.

About 22 % of screen reader users are sighted, but have low vision

– Screen Reader User Survey #9 Results, Disability

The common misunderstanding when starting with accessibility, is that screen readers would only be used by blind persons, and that therefore you could treat visual UI different to screen reader UI.

That is not the case, hence the rule aria-hidden-focus, and WCAG Criterion 2.5.3 Label in Name

Upvotes: 3

QuentinC
QuentinC

Reputation: 14872

You shouldn't put aria-hidden=true on a focusable element, for the very simple reason that there is a contradiction:

  • When an element is focused, the screen reader must say something, so that the user knows what is under focus now
  • The aria-hidden attribute tells the screen reader that this element is irrelevant and should be totally ignored

The first rule is generally stronger than the second because it doesn't make sense at all to say absolutely nothing when the element is focused. Thus the aria-hidden=true is probably going to be partially or totally ignored. For example, the element can be correctly announced when focused, but may not be announced at all because of aria-hidden=true when reading the page in virtual cursor / browse mode. The result for the user is confusion, since sometimes the element appears to be present, and sometimes it isn't.

So, aria-hidden=true and non-focusability always go together. It's always whether both, or none.

However, beyond the pure technical explanation, it makes in fact no sense to have a focusable element ignored by screen readers, if you consider that blind people aren't alone to use them. Screen readers are also used by partially sighted, as well as dyslexic people for example.

Someone may have enough vision to have an usefulness for your scrolling thing, but not enough to read text on screen or using a mouse comfortably. A person with dyslexia, a normal vision, but using the keyboard for whatever reason (there exists a lot), may use a screen reader because reading text on screen is so uncomfortable or exhausting.

So, to wrap up, you have two possible options:

  • Hide the element to screen readers and make it non focusable, i.e. aria-hidden=true + tabindex=-1
  • Keep the element focusable and visible for screen readers, i.e. add tabindex=0 if the element isn't already naturally focusable

If you really think that your thing is only useful for mouse and touch users as well as those using another direct pointing device, but absolutely not for keyboard and screen reader users, go ahead for the first option. In any other case, doing so will lessen accessibility for some users, and you should stay with the second option.

Upvotes: 5

Related Questions