topic Will the "tabindex" attribute for <div> ever be introduced? in ArcGIS Hub Questions

Will the "tabindex" attribute for
ever be introduced?

TimFlynn1 — Wed, 13 Feb 2019 19:27:58 GMT

ArcHub is such a great product, but the lack of accessibility controls is really hamstringing what I'm trying to achieve in my organization. The higher ups are absolutely paralyzed by the ADA issues with public facing web-content. Being able to throw in the "tabindex" attribute in <div> tags would help tremendously.

Re: Will the "tabindex" attribute for
ever be introduced?

Anonymous User — Wed, 13 Feb 2019 19:31:34 GMT

Are you trying to tabindex your own HTML (like something in a text card) or something that the Hub puts on the page?

Re: Will the "tabindex" attribute for
ever be introduced?

TimFlynn1 — Wed, 13 Feb 2019 19:48:11 GMT

Yes, I'm trying to tabindex html inside of a text card. We tested our hub page with a screen reader and it skips over entire rows.

My thought was to put a <div class="hidden" tabindex="0"> at the very top in a text card where I can hide some text for the screen reader to pick up. This way from the very top of the page I can direct differently abled users to call for information.

Re: Will the "tabindex" attribute for
ever be introduced?

KlaraSchmitt — Thu, 14 Feb 2019 13:19:36 GMT

Hello Tim,

Would you be able to share a link to your site? What screenreader and browser combination are you using? We strive to make our app semantic and test with VoiceOver/Safari/OSX and NVDA/Firefox/Windows 10. Your scenario does sound odd and I'd like to take a look at why a screenreader might be skipping rows, since the intended effect of semantic coding is that assistive technologies can rely on their own native controls to access information.

However, if you need to render text to screenreaders only, Bootstrap already has a class for this and you could create a div that has the .sr-only class on it, which will hide the text to sighted audiences, but not hide it for assistive technologies.

-Klara

Re: Will the "tabindex" attribute for
ever be introduced?

TimFlynn1 — Thu, 14 Feb 2019 15:46:04 GMT

Hey Klara,

Right now we don't have it set publicly and I'm low on the totem poll as far as sharing works-in-progress. So I can't provide a link at the moment.

The screen reader used was ChromeVox. It would read out anything you clicked on, but the tabbing order was nonsensical and would outright skip over certain elements. For instance, it would read a collection of 12 image cards in one row, but skip over another set of image cards in another row.

The .sr-only class sounds perfect for what I'm looking for though. Thank you! I will try and provide an update when we get further along and I can share it.

Thanks,

Tim

Re: Will the "tabindex" attribute for
ever be introduced?

KlaraSchmitt — Thu, 14 Feb 2019 22:09:40 GMT

> The screen reader used was ChromeVox. It would read out anything you clicked on, but the tabbing order was nonsensical and would outright skip over certain elements. For instance, it would read a collection of 12 image cards in one row, but skip over another set of image cards in another row.

I just now installed the ChromeVox Chrome extension and ran it through one of our sites that has many card variations. I followed these keyboard commands:

For the ChromeVox extension for Mac, the ChromeVox modifier keys are Cmd + Ctrl.
ChromeVox + Down = Navigate Forward
ChromeVox + Up = Navigate backward
ChromeVox + Right = Navigate forward at a more detailed level
ChromeVox + Left = Navigate backward at a more detailed level
Tab = Jump to next focusable item
Shift + Tab = Jump to previous focusable item

What I observed was that if you moved strictly up and down through rows, ChromeVox did sometimes skip content (within the site I was testing, I observed this only with iframes, but I didn't have 12 image cards like you did.) I poked at ChromeVox documentation and perhaps up/down is generally for landmark roles? Not sure. I did notice that if I used right and left keys to navigate the whole page, which is very similar to how one navigates using VoiceOver, all content was read aloud including that within iframes. Occasionally, it seemed like I got stuck in iframe content and despite my attempts to use ChromeVox + P or ChromeVox + N to skip to the next or previous thing those keyboard commands didn't seem to work correctly. I tried ChromeVox + P, then H and did hear it tell me there were no previous headings, which was accurate of the row I was in, but not the site as a whole. In those cases, I did have to use Tab and Shift+Tab to get to the next interactive content element on the page.

It also looks to me that ChromeVox behaves much like VoiceOver and NVDA in the sense that Tab and Shift+Tab keystrokes take you to links or form elements. Typically, Tab and Shift+Tab are keyboard interactions for sighted users to jump through interactive parts of a webpage. In my experience, most screenreaders do also support that functionality, but that isn't how they navigate a page structurally. For instance, one wouldn't use tabindex="0" to make sure a screenreader read a heading or body text, as a screenreader would do that automatically using its native navigation (in this case, up/down/right/left arrows + ChromeVox keys.) This is how Bootstrap's .sr-only class works. It basically repositions the text really far off the side of the browser screen so no one can see it, but a screenreader will encounter it in the code as if it's just a normal part of the page.

Typically, tabindex="0" is used, when as a developer I might need to allow sighted users the ability to interact with something that is semantically not clickable. For instance, if I had an accordion that was made up of <divs>, but I had javascript running in the background that allowed those divs to act as if they were buttons and thereby receive focus and accept an onClick() event or an onKeypress() event (for the enter keystroke), I'd need to add a tabindex="0" so that someone who was sighted but navigating by keyboard would know they were selectable. For a screenreader perspective, I'd probably also add an aria-role role="button" to the div so that a non-sighted user would also pick up on that interaction, but a screenreader would actually have an easier time interacting with that content without tabindex than a sighted keyboard user would. Content being read aloud by assistive technologies will not necessarily map to a visually focusable piece of content on the page. ChromeVox seems to support it through its native navigation, but for instance VoiceOver uses an overlay dialog, and in my experience, NVDA shows no visible match between what is heard and what is current visible.

I'd be happy to take a look though when you get the site public.

topic Will the "tabindex" attribute for <div> ever be introduced? in ArcGIS Hub Questions

Will the "tabindex" attribute for ever be introduced?

Re: Will the "tabindex" attribute for ever be introduced?

Re: Will the "tabindex" attribute for ever be introduced?

Re: Will the "tabindex" attribute for ever be introduced?

Re: Will the "tabindex" attribute for ever be introduced?

Re: Will the "tabindex" attribute for ever be introduced?

Will the "tabindex" attribute for
ever be introduced?

Re: Will the "tabindex" attribute for
ever be introduced?

Re: Will the "tabindex" attribute for
ever be introduced?

Re: Will the "tabindex" attribute for
ever be introduced?

Re: Will the "tabindex" attribute for
ever be introduced?

Re: Will the "tabindex" attribute for
ever be introduced?