Hey All, I'm not a dev. I'm a completely blind screen reader user working in a professional environment on systems that are required to be 508 compliant. I ran into an issue that I wanted to bring up here. In many of the systems that I am working in the devs have built tables all over the place because we're looking at hundreds and thousands of data points per action. They are using sortable tables like the one described here: https://www.w3.org/WAI/ARIA/apg/patterns/table/examples/sortable-table/
The issue is that this guidance ends up causing a WCAG fialure for screen reader users with 2.4.1 - Bypass Block. The primary issue is that a screen reader power-user needs to get things done quickly. A lot of times bosses are not just happy with "can a person do it?" but also "Can they get the task done quickly?" In a system that I use as the primary ERP for my job, there are multiple tables on each page that have sorting options that utilize buttons that wind up in the "B" navigation quick key. I pushed back on the devs and said that this is a fialure because I'm hitting B to hit the cancel button or the save button and that these sorting buttons are a bypass blocker. The response I received from the dev team is that WCAG guidelines like the link I provided demonstrate that all column headers with sortable functionality must utilize aria buttons. In the link I presented, the table has column headers that are in the B quick nav just like on the system at my job. I am not exagerating when I say that I have to hit B15+ times to get to a button on the website that I'm looking for because there are 15+ columns headers on the same page and some of the pages have more than 25 column headers because there are multiple tables on the same page. The numbers of times that I have needed to sort any of this data is 0, but the number of times that I need to get to save, cancel, or other primary buttons on the website quickly to edit data in the ERP and get out without hitting 50 keys is multiple times throughout the day. Right now I'm using Ctrl+F and searching for Save, which is a lot more than I should need to do. There are only like 5 primary function buttons per page so if the column headers weren't showing up in the B quick nav I'd be able to get to the save and cancel buttons in a matter of seconds with one hand and almost no brain power.
Also, if I need to get to the sorting buttons for a table I just hit T or Shift+T to get to the table header and then arrow to the soritng button I would need. After reviewing the various guidance on the WIIIC website it appears that it would be difficult to require a fix for my issue because the examples provided by WIIIC are recommending the strategy that they are implementing.
I'm sorry if this issue does not conform to standard github requirements. I just want to get this out to folks who can take action on this because screen reader users are one of the highest unemployment rate dmeographics and part of the issue is that speed to complete tasks can be greatly diminished when systems have these sorts of things going on. When I could see I would usually skim right past the sorting headers unless I need to sort and move my eyes right to the data and beyond. A blind screen reader user should be able to skip right past those buttons unless they need them. It's our job to learn how to use a screen reader effectively. Technical requirements should optimize for efficiency once a screen reader user is taught how to use thei tool/ "eyes" effectively.
Happy to answer any questions, but I'm not sure how to get in contact with folks most easily.
Thanks for your help!!
Mike Vaughan
Hey All, I'm not a dev. I'm a completely blind screen reader user working in a professional environment on systems that are required to be 508 compliant. I ran into an issue that I wanted to bring up here. In many of the systems that I am working in the devs have built tables all over the place because we're looking at hundreds and thousands of data points per action. They are using sortable tables like the one described here: https://www.w3.org/WAI/ARIA/apg/patterns/table/examples/sortable-table/
The issue is that this guidance ends up causing a WCAG fialure for screen reader users with 2.4.1 - Bypass Block. The primary issue is that a screen reader power-user needs to get things done quickly. A lot of times bosses are not just happy with "can a person do it?" but also "Can they get the task done quickly?" In a system that I use as the primary ERP for my job, there are multiple tables on each page that have sorting options that utilize buttons that wind up in the "B" navigation quick key. I pushed back on the devs and said that this is a fialure because I'm hitting B to hit the cancel button or the save button and that these sorting buttons are a bypass blocker. The response I received from the dev team is that WCAG guidelines like the link I provided demonstrate that all column headers with sortable functionality must utilize aria buttons. In the link I presented, the table has column headers that are in the B quick nav just like on the system at my job. I am not exagerating when I say that I have to hit B15+ times to get to a button on the website that I'm looking for because there are 15+ columns headers on the same page and some of the pages have more than 25 column headers because there are multiple tables on the same page. The numbers of times that I have needed to sort any of this data is 0, but the number of times that I need to get to save, cancel, or other primary buttons on the website quickly to edit data in the ERP and get out without hitting 50 keys is multiple times throughout the day. Right now I'm using Ctrl+F and searching for Save, which is a lot more than I should need to do. There are only like 5 primary function buttons per page so if the column headers weren't showing up in the B quick nav I'd be able to get to the save and cancel buttons in a matter of seconds with one hand and almost no brain power.
Also, if I need to get to the sorting buttons for a table I just hit T or Shift+T to get to the table header and then arrow to the soritng button I would need. After reviewing the various guidance on the WIIIC website it appears that it would be difficult to require a fix for my issue because the examples provided by WIIIC are recommending the strategy that they are implementing.
I'm sorry if this issue does not conform to standard github requirements. I just want to get this out to folks who can take action on this because screen reader users are one of the highest unemployment rate dmeographics and part of the issue is that speed to complete tasks can be greatly diminished when systems have these sorts of things going on. When I could see I would usually skim right past the sorting headers unless I need to sort and move my eyes right to the data and beyond. A blind screen reader user should be able to skip right past those buttons unless they need them. It's our job to learn how to use a screen reader effectively. Technical requirements should optimize for efficiency once a screen reader user is taught how to use thei tool/ "eyes" effectively.
Happy to answer any questions, but I'm not sure how to get in contact with folks most easily.
Thanks for your help!!
Mike Vaughan