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
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>
<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
aria-level, a screen reader user can easily navigate to these elements without them having
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?”