> 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.
