Your caniuse suggestion would be well received I imagine, i've spent a lot of time on that site. tbh I hadn't come across a11ysuport.io before and looking at all the reds and yellows it doesn't surprise me why it is so complicated to get things consistent with the patchy support across the board.
For most of my UI components that use things like custom dropdowns, I provide a semantic alternative that the browser can render. All I want now is an API that can notify my code there is a screen reader being used so these semantic components render by default.
Accessibility First DevRel. I focus on ensuring content created, events held and company assets are as accessible as possible, for as many people as possible.
The best solution I can offer is to have an accessibility settings screen that lets people select their input method.
A lot of work initially but that is what we have added to the new site we are launching. It also allows you to put settings for colour contrast (allowing you to offer low contrast for people who are sensitive to high contrast!), different functionality etc.
You could pick up some screen reader users by listening for pressing "1,2,3,4,5,6" and then having a message that is in an aria-live region that says "it looks like you are using a screen reader would you like to enable a screen reader friendly mode.....etc.".
Alternatively you could have an option appear when people press "Tab" before your skip link that lets them switch to native elements mode?
Obviously they are all hacks but one of them might work for your use case?
Oh and yeah - the support for accessibility is a nightmare, especially when instead of just having to test in 3/4 browsers you have to test in 3/4 browsers with 3/4 screen readers - it just isn't feasible for 99% of companies (ours included and we eat, live and breath accessibility!)
Already doing the toggle component button which comes just after the "skip to content" button but I love the idea of listening for number presses, is that behaviour consistently used by screen readers? Any other signals that we can infer that a screen reader is being used?
Accessibility First DevRel. I focus on ensuring content created, events held and company assets are as accessible as possible, for as many people as possible.
Numbers are used by NVDA, JAWS and VoiceOver for jumping between headings (actually you should also listen for "h" for "next heading" thinking about it!)
Not 100% fool proof as some people may prefer to navigate by links or sections (using different shortcut keys) however it is the preferred way by most people and “unusual” enough to infer their are using a screen reader.
maybe listening for left and right arrow keys would also work as those are used heavily by people who use screen readers but not so much by people who are using the keyboard without a screen reader.
The problem comes with screen readers on mobiles and touch devices, potentially could listen for double taps and swipes being used but it wouldn’t be very accurate and I am not actually sure whether those commands are intercepted by the screen reader or still bubble through to the page (I would imagine they are intercepted), never really thought about it until today so all of these ideas are just me "spit balling", they could be completely rubbish! 🤣🤣
I think your current solution is the best option (next to having a settings menu to aid discoverability) at the moment though!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Your caniuse suggestion would be well received I imagine, i've spent a lot of time on that site. tbh I hadn't come across a11ysuport.io before and looking at all the reds and yellows it doesn't surprise me why it is so complicated to get things consistent with the patchy support across the board.
For most of my UI components that use things like custom dropdowns, I provide a semantic alternative that the browser can render. All I want now is an API that can notify my code there is a screen reader being used so these semantic components render by default.
The best solution I can offer is to have an accessibility settings screen that lets people select their input method.
A lot of work initially but that is what we have added to the new site we are launching. It also allows you to put settings for colour contrast (allowing you to offer low contrast for people who are sensitive to high contrast!), different functionality etc.
You could pick up some screen reader users by listening for pressing "1,2,3,4,5,6" and then having a message that is in an
aria-liveregion that says "it looks like you are using a screen reader would you like to enable a screen reader friendly mode.....etc.".Alternatively you could have an option appear when people press "Tab" before your skip link that lets them switch to native elements mode?
Obviously they are all hacks but one of them might work for your use case?
Oh and yeah - the support for accessibility is a nightmare, especially when instead of just having to test in 3/4 browsers you have to test in 3/4 browsers with 3/4 screen readers - it just isn't feasible for 99% of companies (ours included and we eat, live and breath accessibility!)
Already doing the toggle component button which comes just after the "skip to content" button but I love the idea of listening for number presses, is that behaviour consistently used by screen readers? Any other signals that we can infer that a screen reader is being used?
Numbers are used by NVDA, JAWS and VoiceOver for jumping between headings (actually you should also listen for "h" for "next heading" thinking about it!)
Not 100% fool proof as some people may prefer to navigate by links or sections (using different shortcut keys) however it is the preferred way by most people and “unusual” enough to infer their are using a screen reader.
maybe listening for left and right arrow keys would also work as those are used heavily by people who use screen readers but not so much by people who are using the keyboard without a screen reader.
The problem comes with screen readers on mobiles and touch devices, potentially could listen for double taps and swipes being used but it wouldn’t be very accurate and I am not actually sure whether those commands are intercepted by the screen reader or still bubble through to the page (I would imagine they are intercepted), never really thought about it until today so all of these ideas are just me "spit balling", they could be completely rubbish! 🤣🤣
I think your current solution is the best option (next to having a settings menu to aid discoverability) at the moment though!