How to Accessibly Rotate Contents with jQuery

[AurelioDeRosa]

Hi.

Let me reply point by point

@brothercake

So here’s the thing … I hate to be critical with people who clearly put an effort into accessibility (I generally save that for people who can’t even be bothered to try). But …

If I didn’t want to hear the opinion of other people I had to stop writing, so comments are welcome.

@brothercake

That’s fine for screenreaders, it wouldn’t make any difference to them, but for sighted keyboard users it means that it now takes 8 Tabs to move through the content, but only 2 of those Tabs are visible.

In practise, you can sometimes get away with the odd 1 or 2 links that are hidden this way, because it only takes 1 or 2 Tabs to get back to something visible (so it tends not to be a big problem with pages that have a single skip link, for example). But in this case, it could take a user up to 6 Tab presses to orientate themselves back onto the visible screen (all the while wondering where tf the focus is!)

So basically, the visually-hidden / offleft approach is not really suitable for elements which are in the Tab order.

To be honest I have never heard or seen any sighted person navigate a website using the TAB key. I’ve seen people that, like me, use the TAB to move along fields of a form but never to navigate the whole website. I think it’s so hard to navigate through TAB that is basically impossible to do that: so many links, so many focusable elements. If you’re powered by a screen reader at least you can skip some contents and jump from a section to another thanks to heading or by jumping to the main menu, and so on. For a sighted person is so much natural and easier to navigate through the mouse or the arrows. Even more I think that most people ignore this possibility, so I don’t see a real problem here. However, this is just my opinion/experience, so you might have a different experience that suggest you that many users do that which is completely fine.

@brothercake

I would suggest, for this example, that you go back to the display based implementation, but then you script it so that you’re monitoring exactly where the focus is. If the focus is inside an element that you’re just about to hide (at the point when you hide it), then you programatically move the focus to the next item. To make that robust, the paragraphs themselves should be in the Tab order, so that the focus() command moves focus to the whole paragraph (then it wouldn’t matter if some of the items didn’t have any links in them).

I don’t agree. This would mean increase the weight of the JavaScript to create a functionality nobody will use (maybe the 0.000001% of the users).

@brothercake

I’d also suggest looking at some ARIA markup to enhance it, probably aria-hidden for each paragraph (true if it’s hidden, false if it’s displayed).

Because of the reasons above I don’t see the need for that. As you said, this is only needed if a developer doesn’t follow my article and wants to implement another technique.

@brothercake

And you should provide mechanisms for users to expand the whole thing (so they can see all the items all at once), and to pause the animation (so they don’t have to hurry to read it).

This comment has nothing to do with the article itself, here you’re arguing against carousels (carousels-ish in this case). Many people, including me, know that they aren’t good or effective in most cases and that they should be avoided most of the times. Still, many developers use them and that’s the main topic of the article: let that a website has a carousel-ish thing in place, let’s improve its accessibility".