Logical Order vs. Tab Order
July 19, 2017 12:00 AM
Screen readers access the underlying HTML code of webpages, so the order in which elements are presented to the user depends upon their order in the HTML code. The term logical order is use to refer to this order of HTML elements presented to screen reader users. The logical order should in most cases correspond directly to the intended visual reading order determined by the layout of the content on a webpage.
There are two basic types of HTML elements: focusable (links and form elements) and non-focusable. Logical order encompasses both focusable and non-focusable elements. Tabbing through a webpage lands on focusable elements and can be used to check the tab order of these elements without a screen reader because it is the system focus that lands on these elements, but tabbing does not include non-focusable elements. Testing with a screen reader is required to verify that the logical order of the content corresponds to the intended visual reading order because there is most often a combination of both focusable and non-focusable elements. An automated check cannot provide this verification.
It is possible, however, to assign focus to non-focusable elements with the tabindex attribute. A tabindex value of 0 makes a non-focusable element focusable and the element appears in the logical order according to the underlying HTML code. A tabindex value of 1 or greater assigns an explicit tab order. WebAIM asserts that “This is almost always a bad idea.” This is presumably because if specific tabindex values (>0) are assigned to elements, the situation can quickly become complex with significant implications for accessibility. The logical order and the tab order can diverge at this point. This means the screen reader user, who routinely switches between using the arrow keys to navigate non-focusable content and the tab key to navigate focusable content depending on the task at hand, can be moved around erratically on the page. This clearly renders the page inaccessible and must be corrected.
When publishing to HTML, Lectora assigns explicit tabindex values to elements according to their order in the Title Explorer. This allows some control over the logical order of page content. Any element marked “always on top” does not appear in the order as might be expected in the title explorer. Many ordering mistakes are due to this checkbox being inadvertently checked—of course, elements defined at different levels would be grouped together and appear in the order according to the level at which they are defined (titleundefinedpage).
There is a bug relating to the assignment of specific tabindex values when publishing to HTML from Lectora. The elements are grouped into an array in the javascript code generating the page. Tabindex values are assigned according to the position of the element in the Title Explorer. The problem is that the numbering starts at 0; the first element receives a tabindex of 0. The second element receives a tabindex of 1. A tabindex of 1 is first in the tab order. The first element in the Title Explorer receives a tabindex of 0, so it appears last in the tab order because a tabindex of 0 appears only after all positive integer values (1, 2, 3, etc.). The result is the intended first element in the tab order is actually last in the tab order.
This could be corrected if the Lectora developers were to simply start numbering the tabindex values at 1 instead of 0. This should be corrected, but there is a do-it-yourself workaround: if an image with both “empty alt text” and “always on top” is defined at the top in the title level, this would ensure that this element would have the effect of moving the array over one value, and the next element would be assigned a tab index of 1 and be the very first element in the tab order. Lectora does not seem to apply a tabindex value to every element in the Title Explorer, but it does skip over the tabindex values for those elements that do not receive an explicit value.
I also noticed that Lectora can assign a tabindex value to text blocks. This would appear to make these text blocks appear in the tab order, but it does not work: when tabbing to these text block elements using a screen reader, they are not read by the screen reader. This is due to the internal structure of these text elements; they have the simplified structure as follows:
Discussion (11)
Thank you William - I've been studying your replies to my question and this posting. Very informative, and really got me to thinking.
In reviewing your post above, it piqued my curiosity even more, and prompted some additional questions:
- What do you mean by an automated check?
- How do Heading tags come into play; can they give focus - or must we rely on ARIA?
- Are you essentially saying, that if we use ARIA-Label and ARIA-labelledby attributes, for non-focusable (i.e., text) elements it would resolve tab order issues with screen readers?
- Is this something I can do now - I'm thinking it's labor-intensive to go into the code? "
I ALSO CHECKED MY ONLINE CLASS ON ARIA, AND I FOUND SOME RELATED INFORMATION: (I trimmed this information down)
"Wherever possible, use the non-ARIA methods for supplying names and labels to elements, because ARIA is really meant to fill in the gaps where methods do not exist. Where methods already exist, it makes sense to use them. Additionally, these older, more established methods usually have the best support among assistive technologies, in particular among older versions of assistive technologies."
This one caught my attention too:
"Use tabindex="0" Sparingly
undefinedWhile it is true that adding tabindex="0" to an element makes it keyboard-focusable, thus allowing screen readers to read the text, screen reader users still can't interact with this text in the normal way. They can't read one line at a time, or one word at a time, or check the spelling of words, or do any of the other text-related operations that they're used to doing. They can only tab to the element and listen to it in its entirety. If they pause the reader, it won't pick up where it left off. They would need to tab away from the element, then tab back to it and listen to the whole thing over again.undefined
Most software authoring tools include an automated accessibility check of some kind. This is a feature that gives you feedback on how your document/title/webpage/presentation (depending upon the published format) complies with a given accessibility standard (most often WCAG 2.0 AA criteria nowadays with the Section 508 Refresh which explicitly references WCAG 2.0 AA criteria). Most of these automated checks specifically caution against relying upon them as a guarantee your document is accessible because they can only check a subset of the standards in questions; for example, they cannot verify the proper order of the content elements because this depends upon knowing the intended reading order. An automated check is only one step; full testing requires manual and functional testing as well.
Applying a heading tag to text will not make it focusable. A tabindex attribute would have to be added to the heading tag to make it focusable and appear in the tab order. As a general rule, this should not be done unless there are specific factors motivating making the heading focusable.
My comments on the use of aria on text blocks was confusing. I should explain in greater detail. In testing pages with Lectora, I noticed that there were routinely more tab stops in the tab order than the number I expected from only those elements that are focusable by default. When I examined the underlying HTML code, I noticed that Lectora often inserts empty anchor tags into the published HTML pages. This seems to be done to add functionality (actions) to various elements. I have not looked into this in sufficient detail to discover the exact conditions under which it is done; it seems to be inconsistent; however, some of these tab stops appear in the tab order, but they cause a problem for screen readers. Often nothing is read or something from elsewhere on the page is read, so it can be confusing. Since these tab stops are already inserted into the published HTML pages, one way to mitigate this issue would be to use the aria-labelledby attribute. I do not recommend using this (and adding a tabindex value to text blocks). This would certainly not be a best practice for accessibility.
We often have scant control over the published results of software authoring tools like Lectora. Developers make certain decisions on exactly how the content will be coded into actual HTML. Sometimes it is possible to change our technique within the software tool to achieve a given result; sometimes it is not. I often have to work with the hand I'm dealt in terms of how the content is coded and whether or not I can modify that code somehow. Lectora can introduce these ambiguous tab stops in the tab order, so the aria-labelledby attribute is one way of dealing with this. I shouldn't have to deal with it, but that is not always my choice.
It can be time-consuming and labor-intensive to drill into the code at times. That is where the severity of the issue and the benefit to the user (improving accessibility and usability) are decisive. In the process of doing so, you can build up techniques and tools that make it easier the next time. One would hope that the Lectora developers would eventually listen and modify the algorithms used in the publication process, so such fixes weren't needed. That is where I hope this group can help.
I agree totally that basic HTML methods should be used in preference to aria techniques. The issue here is that Lectora publishing to HTML uses some non-standard HTML coding that causes problems for screen readers,. Sometimes aria can be used to make screen reader behavior more consistent. It would be better to change how Lectora publishes to HTML, but I do not have that option.
The explanation of the problem screen reader users would have with a focusable text block is incorrect. It shows a misunderstanding of the difference between logical order and tab order. They are different, but they do not have to be. On a simple webpage where no element is assigned specific tabindex values, they are identical; the tab order is just a subset containing focusable items (links and form controls). When tabindex values >0 are assigned to elements, they can diverge, and the situation becomes complicated.
Yes, that makes sense. At first, I didn't catch what you were referring to.
So for anyone else who is wondering this would be (in Lectora) the option to check for Accessibility Check on the Tools menu.
Thank you William.
undefined
I have a question on the "always on top" setting. I find that if I don't select this setting, then my buttons and videos are not clickable. How do you get them to work then?
Has anyone noticed strange tabbing order lately? For my navigation buttons, I've typically grouped the next and back button together, and place them very last at the top of my title explorer under my AU and before my first chapter. Grouping them gives me the option to set their reading order to last. My skip to content target also sits just above my next and back group in the title explorer, I have chapter buttons that need to be skipped. Tabbing through my published course, without a screen reader it does not tab through the elements how I would expect them to. Also some images that I've marked with the "empty alt tag" gain focus. I'm learning html and through google using F12 to look at my course in my browser I noticed one picture marked with "empty alt tag" had an tabindex = -1.
I wish I knew the answer... what would cause things like this to change?
undefined
Benjamin,
First of all, the tab order will be the same with or without a screen reader running on a system. Tab order can be verified without a screen reader. What sort of strange behavior in the tab order have you observed? I heard from the support team last week about a bug in the tab order that I discovered (see my original post in this thread). I'd be interested in looking into it more if you can give me a more detailed context. That is eventually what the developers will need if this is a bug in how the Lectora files are published to HTML. I think this is an important function that we can perform: identifying accessibility issues in the Lectora software publishing to HTML.
For buttons that would need to be skipped in the tab order on certain pages, I think it is a good practice to define a variable to track current location. This variable would then be modified on those pages where the button would be skipped (with a show undefined the disabled button does not appear in the tab order, but it is still present in the logical order with a "button unavailable" message read by a screen reader.
I've noticed that images with an action attached--even if no action is specified--, receive a tabindex and appear in the tab order. You might check to make sure there is no action on the image.
I haven't encountered a tabindex of -1. It would be interesting to find out under what conditions that happens.
Hi Windy -
I replied via mobile the other day but don't see my response posted here. Have you ruled out the layering order in the left pane (i.e., Title Explorer)?
undefined
Windy,
undefined
I have not encountered that issue. I suspect it is a combination of other settings that produces the context in which the "always on top" setting is decisive for clickability. Can these controls be activated via the keyboard or does it only affect the mouse? It would be instructive to look at the HTML code for the controls where this setting affects performance to compare the details of the HTML coding.
Discussions have been disabled for this post