DEV Community

loading...

Discussion on: 🤷‍♂️ W1y d2s a11y h2e to be so b4y c9d a1d i10e? 👿

Collapse
danm_c137 profile image
Daniel Morrison • Edited

Your 5 points are solid, but when you want to go beyond semantic elements, things instantly get complicated. A custom dropdown (select) menu is the classic example. Why does a role element have to be the direct child in order to be valid. As long as it is a descendent, shouldn't that be enough. Screen readers having inconsistent behavior when content is dynamically updated. Personally, when using newish APIs (Grid /Flexbox for example), I find it time-consuming and hard for my markup to be valid, be described properly with screen readers, work consistently with a mouse and keyboard and fit a tight UX design.

Collapse
inhuofficial profile image
InHuOfficial Author • Edited

That is the point and I completely agree, you want to create a custom select, be prepared to spend hours learning aria attributes that you are also very likely to get wrong. One example will use aria-haspopup and the next will not have it and you have no idea why?

I think what makes it worse is that you can even do everything right and still get it wrong!

For example:

<div role="status" aria-live="polite" aria-atomic="true" aria-relevant="text">
     <!-- adding content here should be read by a screen reader -->
</div>
Enter fullscreen mode Exit fullscreen mode

Now that is perfectly valid and correct use of WAI-ARIA to create an area where you can add status updates etc. and they will be read out by the screen reader.

The problem is that the aria-relevant property is not well supported by browser / screen reader combinations.

What aria-relevant is meant to do is look at the contents of an aria-live region and say "I have seen that before so I won't read it again" so that it only reads amendments (I am simplifying it as there are different behaviours of aria-relevant such as "additions", "removals", "text", (and combinations such as "text additions"! Yet again complicated!) but that is the basic gist of it).

What happens in the real world is that the whole contents of that aria-live region will get read out each time you add something to the region. Which is horrendous.

So do you follow the spec or do you replace the content of the aria-live region each time to avoid this?

You have made me think that we need a "caniuse" for aria coupled with some simpler examples that are a bit more opinionated (e.g. "use this as a skeleton for your custom select, you can add this content in here and you need this JS for the functionality. Here are 10 things to check once you have added your content...").

It would strike the balance between "ease of use" and "flexibility".

What do you think?

Collapse
danm_c137 profile image
Daniel Morrison

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.

Thread Thread
inhuofficial profile image
InHuOfficial Author • Edited

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!)

Thread Thread
danm_c137 profile image
Daniel Morrison

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?

Thread Thread
inhuofficial profile image
InHuOfficial Author • Edited

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!

Forem Open with the Forem app