5

I'm trying to fix up a site made with the adaptAuthoring tool after an accessibility audit. One of the audit items is a complaint about the very large number of tabs needed to navigate the document.

Adapt sells itself on (amongst other things) accessibility features and even WCAG compliance. I have my doubts. Maybe someone here can help me out.

I've noticed that almost all content generated by adapt authoring is given tabindex=0, even non-interactive content such as headings, lists and paragraphs. This does not seem like 'best practice' to me. It certainly requires dozens of additional tab-strokes to navigate documents made with the framework.

I've seen it mentioned in many places (especially including w3c documentation) that all interactive content should be available via tabbing, and that tabindex=0 provides that functionality in those cases where the element is not focusable by default.

From that we might conclude that non-interactive content should not have the tabindex=0 setting, although I have seen examples where (e.g.) ordinary paragraphs are given this setting.

As I understand it 'virtual mode'/'browse mode' should be sufficient for reading text, and it's clear that the extra tabstrokes get pretty tiresome when browsing non-interactive content, not least because screenreaders often announce the type of the elements as well as the content, but I haven't found an explicit recommendation not to use tabindex=0 in these cases.

So, did adapt do the wrong thing? If so, I want to file a bug with them.

2 Answers 2

11

Adapt did the wrong thing for the right reason. The blog you referred to had some great information. Change the question from "Is accessibility required?" to "Is accessibility desirable?". Based on their blog, they have a good concept of what accessibility is but their concept of how to implement accessibility isn't accurate. They seem to think that those that need accessible accommodations should be segregated by turning on an "accessible mode". As we know from just about any country's history, segregation is not a solution.

Their accessibility page says:

All Adapt courses have the accessibility feature built-in. However, it must be enabled during development by the course author before the course is published.

So, does the course author have to make the decision whether to turn that feature on or not? Is it up to the course author to decide if accessibility is desirable (the word they used in their blog)? Why is there an option to turn it on? Why is it not always on? Or rather, why is there an option at all? The default should be to build an accessible interface.

That same option/segregation is offered to the end user too.

To activate the accessibility feature while viewing a course, press the Tab key. A button is displayed: "Turn accessibility on?" ... Once the feature is activated, pressing the Tab key navigates the learner through content. Focused content regions are highlighted with an outline. And ARIA labels are enabled for assistive technology such as screen readers.

What's different about the interface that requires accessibility to be turned on? Any interactive object you can navigate to with the keyboard should always have a valid label or name (which is what ARIA labels give you if you can't provide a label/name with a native HTML element). Always. Why would you ever not want a valid name for an object? You shouldn't have to turn that option on.

A user that requires a screen reader to interact with the page does not want to be treated any differently than a full sighted user. They want to navigate to interactive objects using the TAB key just like any other keyboard user and they do not expect to tab to heading or paragraphs or lists or whatever.

Screen reading software has fantastic tools built in that allow for navigation to non-interactive elements. You can press the 'H' key to go to the next heading (and hear it read), or for more granularity, press the '2' key to go to the next <h2>. You can press the 'L' key to go to the next list, or the 'I' (eye) key to go to the next element in a list. Press 'R' or 'D' (depending on the screen reader) to go to the next "landmark". None of these elements are natively keyboard accessible and are not expected to be. They should not have tabindex="0".

Now, none of these shortcuts will work if the content author does not use native HTML tags that have built in semantic meaning. That is, use

<h2>Really important info</h2> 

instead of

<div class="big-bold-font">Really important info</div>

Screen reading software does not know that the "big-bold-font" class means the element should be a heading but it definitely knows what an <h2> is. In the latter case, if you have to use a <div>, that's where ARIA attributes come in:

<div class="big-bold-font" role="heading" aria-level="2">Really important info</div>

With the correct semantic meaning, whether provided by native HTML tags such as <h2> or augmented by using ARIA attributes such as role and aria-level, a screen reader user can easily navigate to these elements without them having tabindex="0"'.

That's why I think Adapt understands what accessibility is but does not understand how accessibility is used.

So that's a really, really long answer (sorry) to what could have been a simple answer. Your OP title is

"When is it 'wrong' to put tabindex=0 on non-interactive content?"

Answer: Always.

6
  • @slugolicious, do you happen to have any good reference docs that say: Always wrong to put tabindex="0" on non-interactive content?
    – morgs32
    Dec 5, 2018 at 19:43
  • 3
    @morgs32 Yes, the official W3 doc on the tabindex attribute is defined at w3.org/TR/html53/editing.html#the-tabindex-attribute and in the big "warning" it says "authors should only make elements focusable if they act as interactive controls or widgets" Dec 5, 2018 at 23:08
  • This is one of those answers that makes me want to hammer on the upvote button repeatedly. There are two major problems with a11y: People not taking it seriously, and people trying to be accessible, but doing it badly. Putting tabindex=0 on non-interactive content because you think that's how you can make it accessible is the latter. It actually makes keyboard navigation harder because you've got too many tabstops.
    – daiscog
    Sep 7, 2023 at 10:45
1

"When is it 'wrong' to put tabindex=0 on non-interactive content?"

Answer: Always.

Someone should probably tell W3C that: Feed Display example

It's referenced in MDN documentation as well.

Not that I don't agree with you however: interactive elements shouldn't be focusable. However, there appears to be a lot of confusion around this topic, especially when you factor in WAI-ARIA guidelines as well.

**UPDATE: Here's another W3 example putting a tabindex="0" on an non-interactive element. The reasoning behind it stems from the fact that the content will otherwise be inaccessible to screen readers and other Assesstive Technologies.

1
  • 1
    The feed example specifically says "This proposal does not yet have ARIA Practices Task Force consensus". The "Update: another example" is the tab pattern and the tabs are interactive so correctly have `tabindex="0". Sep 8, 2023 at 22:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.