I’ve been working on a video-based eLearning platform recently. We (the client and myself) seem to have tied ourselves in knots regarding how best to implement tab order and focus placement to give the most efficient user experience for sighted keyboard users and screen reader users. Having finally unravelled those knots, it all looks pretty simple really so I thought I’d share it.
To give a brief description of what we’re dealing with (unfortunately I can’t share a screenshot or give a URL), we have an eLearning course page with a clickable course table of contents on the left and a media player on the right.
Anecdotal evidence suggests that most users, most times, want to start playing the current video as soon as they launch the course, so a decision was made to put the play button (the leftmost button on the player control bar) first in the tab order, then for the tab order to continue through the player controls before jumping to the table of contents.
This goes against the usual practice of the tab order mirroring the visual layout by starting at the top left and proceeding more or less top to bottom, left to right. There are obvious and less obvious reasons why this mirroring is a good idea.
The obvious reason is that for sighted keyboard users, following the focus as you tab is difficult if it doesn’t go in the expected order. Especially if the very first tab puts focus a long way from the top of the page. Starting at the top and going top to bottom, left to right, is logical and expected.
A less obvious reason in our case is that if the user wants to go to the course table of contents, they will naturally tab backwards, up the page, because that’s where they see it. However, if the player controls are placed first in the tab order, tabbing upwards past them will move focus into the browser toolbar, not into the table of contents. This is confusing and disorienting.
Another less obvious reason is for screen reader users. If tab order begins in the middle of the page then it appears to them while tabbing as if the player is at the top of the page and is followed by the table of contents, because the browser toolbar comes between the player and the menu. Not a problem on its own, but if you then return to the top of the page (where screen reader users often go to reorient themselves) and arrow down through the content, the table of contents comes first and the player after. This can be pretty confusing. First it’s one way round, then it’s another. It’s because tab order doesn’t match reading order.
So rearranging the tab order was a bad decision. Fortunately, there is a better way to achieve what we want, using focus placement.
When the page loads, focus is automatically moved to the Play button, where most users will want to be. As long as this is visually obvious then it should work well, even on first use. It doesn’t affect tab order, which still starts at the top of the page, at the table of contents.
We can use focus placement to get around other problems with visual placement too.
Courses are made up of numerous short topics which users play one after the other. The player control bar has the Play button on the left then a few other controls, then Previous Topic and Next Topic. Users are complaining that when a topic has finished playing, they have to tab five times to get to the Next Topic button. Then after going to the next topic, they have to shift+tab five times back to the Play button to start the video. They’re tabbing backwards and forwards like yo-yos! So some of them have requested that the Play button be put next to the Next Topic button in the tab order. Except the visual order has to remain the same (nobody wants to redesign the player) and tab order would then not match visual order which we know is not a good thing.
A solution is, again, to use focus placement:
- On topic load – place focus on Play
- During playback – keep focus on Play, which is now Pause
- When the topic finishes playing – place focus on Next Topic
- After a Next Topic transition – place focus on Play
So focus is always where you (probably) want it and tab order is preserved. Job done!
Now all we have to do is user test the solution. And convince some of the team that ‘tab order’ and ‘focus order’ mean the same thing and that by moving focus we are not changing tab order. It’s partly the language problem that got us confused in the first place.