0

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.

4

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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