Personal site to archive accessibility-related learnings, mostly focused on technical implementations.

Writing

Should developers work around assistive technology bugs?

A few months ago, I wrote about solving an issue with VoiceOver and list–style–type: none;. The response that I got was surprising, for a few different reasons.

The first surprise was that people actually read the post. I am not used to anyone reading anything that I write. If you are reading this, thank you! Please check out my other accessibility articles.

After that, I was surprised at how little people were aware of this bug. I wondered if people were really testing their work with Safari and VoiceOver. Perhaps nobody thinks this is as big a deal as I thought?

The biggest surprise though was the negative feedback over my solution. I got a lot of feedback from various people that felt that I should not be attempting to fix anything that was caused by what was essentially a VoiceOver/ Safari bug. I really did not think 1 line of CSS could cause so much noise! I was also surprised because, I am not nearly the first person to suggest code to fix a browser/ assistive technology defect.

Most comments were around the typical instruction of "Use standard web dev and file a defect!" The funny thing about that is that I WAS using standard web dev (a simple unordered list) and defects had already been filed for years. So the question is, when you have done everything "right" in your attempt to do the right thing and it still doesn't work, at what point do you give up and when do you push on and try to make it right?

And that question is only for the accessibility community, because it's already common for the rest of the web dev community to do so.

I can understand if you don't agree with the "problem" or my solution, it works for what I need and that's all the matters. What was confusing was how different the attitude was towards addressing issues with assistive technologies. I grew up in the field of front end engineering during a time when fixing browser inconsistencies and flaws was a big part of the job. jQuery built a cult by normalizing DOM and JS, CSS Resets were a required asset as much as HTML5-shim was, and Modernizr was used to detect more unsupported features to polyfill. Today we use transpilers and post-processors to support future code in today's browsers, and web components to style elements which normally are not stylable (which IMO is not a good reason).

But it's too hard!

Another comment I heard was that forcing or exposing this type of "hackery" would turn off developers from accessibility, making it too hard. I know this happens a lot, I am dealing with it right now at work, but I honestly think it's BS and I just cannot support it. You have these "brilliant" JS developers building their complex solutions that immediately melt into babies when you mention accessibility.

Webpack config is hard, but people do it.

What to do?

We always say that a big reason to do accessibility is because "it's the right thing to do" so how do you do the "right" thing? As with everything else, it depends. I am not going to cop out and leave it right there though. I can tell you what I do/ think.

Definitely start with standards. HTML, for the most part, has been accessible since the beginning of time. Don't fool yourself thinking you can recreate everything and be as inclusive as possible. It doesn't matter which hot framework/ library du jour you are using. Don't automatically assume that ARIA will bail you out.

If after testing, you find something not working the way you think it should, you should check to see if a defect has already been filed first before opening your own. You might end up finding the solution you need. If you find an already-open ticket, make sure to add any relevant information. If you don't find a ticket, go ahead and open one making sure to include any information needed to reproduce the issue and your expected results. Here is a list of places to research/ file defects:

With those 2 steps out of the way, you have been a good citizen to the broader accessibility community. Now it's time to figure out what YOUR response is going to be.

Do nothing

Just wait for the screen reader or browser to fix the defect. Based on the backlash I got, this is perfectly good and acceptable solution according to others. What it means is that you have to wait for that vendor to research, prioritize, fix and deploy those changes. You have to hope that the vendor agrees with the defect and is inline with their internal roadmap. They have their own timeline, and need to cater to the majority of users, so there is no guarantee that it will happen in a reasonable amount of time. Once it is fixed, then you have to hope that your users are good about updating. In the meantime, their experience may suffer.

Suggest an alternative

You could always suggest that your users use a different browser or screen reader, since their preferred choice does not support the features you have implemented. I offer this as a suggestion, but I honestly don't think it is a proper option.

Nicholas Zakas, who's books I owe a lot of my engineering career to, recently posted this thread on Twitter:

Periodic reminder: "Please try in another browser" is something your support team should never say to a user. If that's actually the "fix" it means your engineers are the problem.

— Nicholas C. Zakas, @slicknet

We would never accept telling a user of assistive technologies to try a different browser/ AT. We know that it's not that easy with cost, platform dependency, learning curve, and long-time settings/configurations that are in place. We know our job is to smooth things over and remove barriers. Switching tech is not how you do it.

Work around it

Maybe you can change the feature, or the way it is implemented? Can you postpone the feature? Change the design?

Engineer a solution

You could always investigate a way to fix the issue for your users, to ensure that they have the experience they deserve. Before you go down this path, there are some things you need to consider. In reality, you should treat this the way you treat any other functional defect.

For example, does this issue happen in all browsers/ assistive technologies or does it happen with a specific combination or version? If it worked in a previous version but is broken in a newer version, I might be less inclined to fix. Sadly this happens a lot (cough JAWS).

If it is an issue for all supported browsers/ AT combinations, then I would consider that a good candidate for fixing. How often does this happen? It's possible, either an HTML or ARIA spec is not implemented fully or maybe you are doing something innovative. It could work very well on desktop browser but fail miserably on iOS/ Android.

In most cases, this is going to be an issue that only occurs in a specific browser or assistive technology. This is where it is important to have analytics in determining whether or not you should fix it. It's easier to make a decision if it is a heavily used browser. But how do you determine to patch a screen reader defect?

Use Analytics

We are still unable to programatically determine assistive technology usage in browsers, via UA strings, etc., so it is really hard to know unless you query the user directly, and that is not always possible. In general, you can make some pretty good assumptions based on the browser itself due to what we know about common combinations.

Basic combinations can be Safari and VoiceOver, IE and JAWS, and NVDA with Firefox. This mainly has to do with the underlying accessibility API that is being used, and matching between browser and AT is almost always the best way to go. There is some significant usage with JAWS and Firefox as well, but I would say that is a secondary consideration. I expect that combination to grow until Edge is fully supported by JAWS. Until then, users are expected to use IE11. I did mention earlier that it's not the best thing to expect users to use a different browser, but in this case users are probably already used to using IE so I don't think it is that big of a burden.

Again, those are the most common combinations you could expect and the 2017 WebAIM Screen Reader Survey helps support that.

Another thing to consider is the severity of the defect. Is it pretty important to functionality? Does it greatly impact the user experience? Is it on a heavily used feature or function? Again, analytics will help here. If the issues occurs in a low-usage browser on a low-usage page/ feature, then I wouldn't consider it a good candidate for immediate fix, you probably have a bigger bunch of kale to juice. (I just made that up, not too many people in the Bay Area are into frying fish these days.) Make sure that your basic accessibility is handled. If your analytics show that a lot of users may be impacted, I would definitely go for it.

One important thing is that you should never break one feature to fix another. Be sure to test thoroughly!

DANGER!

I can't stress it enough, RESEARCH BEFORE YOU DO ANYTHING! Sometimes what you think is a bug is really not. A good example is when developers on MAC's put tabindex="0" on everything because the TAB key doesn't work in Safari. In reality, this is the default setting in Safari (Check the Advanced preferences tab).

Another thing is just playing ARIA roulette and throwing whichever ARIA role/ property/ state sounds good. Even worst, just making up your own ARIA. ARIA really does require a bit of experience/ knowledge to implement properly as the affects are not as easily noticeable in the browser as CSS/ JS and the impact can be very detrimental to a user.

Why did I do it?

We use lists a lot, for menu's and navigation. I felt that knowing the number of items in a list was important and greatly improves the user experience. It took me about 15 minutes to find the solution, which did not impact other browser/ AT combinations. I thought it was big impact for little cost. It can be easily implemented into a framework as a utility, atomic class, or any other easily removable CSS. Put some engineering into it!

To be clear, this wouldn't be applied to every list. But if you are using a list because it makes sense semantically and have the need to remove the bullet for aesthetics, such as for menu's or navigation, then it would be important to maintain those semantics.