Remove role=presentation from the <table>
Closed this issue · 3 comments
-
A screen reader user who is familiar with table navigation commands will prefer having the option to navigate that way versus arrow keys
-
The up/down arrow keys do not help much when the current column is unknown to them
-
Removing the table semantics also means the column headers (the days of the week) are not announced.
-
You can use ARIA grid roles instead if you want to convey that the entire table is a single compound control (which may be most appropriate).
-
From experience training and testing with users, asking them to switch modes (particularly into Applications mode) will be ignored (if even understood).
Hi @aardrian , thank you so much for taking the time to provide feedback, I really appreciate it! 💯
The issue of table semantics was something that I thought a lot about before I started working on this project. I will try to layout the reasoning behind why I chose role=application, and you can tell me if that makes sense or not:
-
The main thing I wanted to achieve with this calendar overall was simplicity, especially for novice and non-expert users.
-
Maybe my experience is not the same as yours. But when I have tested with screen reader users of varying proficiency, tables have consistently been the interface elements that causes the most problems. I've met expert users who navigate tables quite well, but I've also encountered users who have not learned the commands and are frustrated by the experience. One woman and long-time screen reader user told me: "When I hear there's a table, I want to throw my computer out the window!". And I've seen otherwise very proficient iOS VoiceOver users struggle with mobile tables.
-
So basically, I wanted to see if I a simpler experience was possible, even if that comes at the cost of straying from recommended patterns.
But you are right of course that there is still a big challenge of communicating how the datepicker works. And telling the user to manually activate applications mode might not cut it, I realize now..!
The risk with the application role is that it can leave a screen reader user stranded, unable to use the commands they know to get out of the widget. As Léonie Watson notes:
The application role prevents the screen reader from intercepting keystrokes, and passes them back through to the browser as though the screen reader wasn’t running.
This can strand unskilled and semi-skilled screen reader users. Skilled users can force the mode in some cases.
I have conducted tests on tables with unskilled, semi-skilled, and skilled screen reader users, with various levels of vision (full-, low-, and no-vision users). I have also seen users get frustrated with tables, which is all the more reason to ensure they are tested when they contain interactive features, and that testing must be done with the target audience (initially).
A table can still be navigated with standard cursor navigation (arrow or swipe), and if it contains controls then Tab works for those controls. The advantage is that the column headers are still announced in many cases. Alternatively, you can use aria-labelledby to do that lift, but then you get a verbose pattern that will frustrate other users.
My suggestion, absent the ability to test with the same users you have, is to build two versions and run it by them. See which performs better. Then adjust the prototype with instructions and test. Then try some other patterns and test. And so on.
In the end, you may find your final pattern requires a toggle or user preference to enable or disable roles and features.
Either way, I avoid wholesale changes to common patterns when only a small set of my testing pool gets frustrated. That often tells me I need to offer more options (variations, instructions, etc.).
Hi @aardrian
I have reconsidered my previous stance. The updated version now follows the WAI-ARIA APG pattern using role="grid" (https://www.w3.org/WAI/ARIA/apg/example-index/dialog-modal/datepicker-dialog)
I hope to get some real-life user testing with screen reader users in the near future to validate that it works OK