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.).
from inclusive-dates.
Comments (3)
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..!
from inclusive-dates.
The risk with the
applicationrole 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: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-labelledbyto 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.).
from inclusive-dates.
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
from inclusive-dates.
Related Issues (20)
Recommend Projects
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
Recommend Topics
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
web
Some thing interesting about web. New door for the world.
server
A server is a program made to process requests and deliver data to clients.
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Visualization
Some thing interesting about visualization, use data art
Game
Some thing interesting about game, make everyone happy.
Recommend Org
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.