Compare the experience of using the tabs and the modal dialog before and after clicking the "apply fix" button. Peruse the notes for more information.
http://paypal.github.io/bootstrap-accessibility-plugin/demo.html#
This plugin is very well done. Unfortunately the demo cited above does not use the latest version of the plugin (1.0.2). Thus, I've provided a few examples of the improvements made in tab and collapsable accessibility on this page, and explaine why I believe they are important.
Be sure to click "Apply Fixes" to see my changes!
shift focus on open. Screen readers only fully react to the dialog role when an object within the dialog gains focus and the focus was previously *outside* the dialog. The screen reader will then automatically read the text in the element pointed to by aria-labelledby and aria-describedby. If focus is not transfered to a focusable object within the dialog, nothing is read. I have implemented this in the "shown" handler for the modal.
Previous incarnations of the bootstrap accessibility plugin (and other accessible tab navigation implementations such as jQueryUI) insist on the use of the tab role on tabs and accordion triggers. However, this role turns off all other element semantics and forces the screen reader into application mode. Since application mode turns off all document navigation, the author is burdened with providing all keyboard nnavigation herself. In the case of accordions, it is useful to make the accordion triggers headings so that one can move through the content from trigger to trigger quickly. For instance, if your in the middle of a long panel of accordion content which may contain focusable items, it will be difficult to find one of the accordion tabs since tabbing will move you through the focusable elements in the currently showing panel. If the triggers were headings, then pressing next/previous heading keys would move you to a trigger (or to a heading outside the accordion if no triggers in that direction). This seems to be a property of the role itself, since all screen readers which use two modes switch to application mode when encountering an element with role="tab".
Interestingly enough, the accordion example on the demo page cited above uses headings on the triggers, but they don't show up because the version of the bootstrap-accessibility plugin used on that page uses tab roles, which removes heading semantics from the tabs!!
*** Note: The latest bootstrap-accessibility plugin (1.0.2), which is the one used on this page, removes all tab roles. This is a huge win and the bootstrap accessibility team should be commended for making this change! Get it from: https://github.com/paypal/bootstrap-accessibility-plugin
A side-effect of removing tab roles is that the aria-selected attribute now has no effect. Unfortunately, aria-selected only effects roles tab and option. Seems to me that many more things are "selectable"; the attribute should have an effect on many more roles.
In any case, we use the aria-expanded attribute on active tabs, and implement that here. We suggest this be used in place of aria-selected in the plugin going forward.
A tabindex value of 0 is used on active tab panes. This causes the screen reader to read the entire contents of the tab when attempting to tab to a focusable item in the panel. This is very confusing and is unnecessary. A tabindex value of -1 is maintained on non-active tabs by the plugin; we suggest this be true on active tabs as well. This will allow focusing the tab panel if desired, but will remove it from the tab order.
The plugin tries to keep the active tab in the tab order by applying tabindex="0" to it. However, it takes the other tabs out of the tab order via tabindex="-1". This is confusing since, at least in this implementation, tabs are links and one expects to have links in the tab order. People who navigate via keyboard also expect this, whether or not a screen reader is used.
Here are three standard links, with no additional tabindex attributes applied.
They appear in the tab order in in html order.
This means that a screen reader user reading via arrow keys and a keyboard user tabbing through the page
will encounter these links in the same place and same order.
MIT
Google
WGBH
Now we'll add positive tabindex values.
If you attempt to arrow to one of these via screen reader and then press tab, you will not end up where you might expect!
- arrow to Google and press tab twice (where do you end up);
MIT
Google
WGBH
This entire paragraph should be focusable and in the tab order. Fortunately, it is not that long. However, in the default bootstrap-accessibility plugin implementation, each tab pane (the content which is shown / hidden via clicking on the tabs) is tagged with tabindex="0".
No messages at present.