When we think about producing online content we can establish that there is still a lot of software needed between the content producer and the end user. We need to have an operating system on both sides, we need to usually have a browser on both sides (sure there are some CMS that run as independent software, but they are really exotic). Some end users need to have assistive technology to consume the content.
So we can think about it as a chain, in a way. And I’ve skipped the developer tools needed to even make the whole chain possible. There I will only mention accessibility linting, accessibility plugins for continuous delivery and accessibility plugins in the browser that are (or at least should) be used to make accessibility integrated as soon as possible.
All this different software is just software. It comes with bugs. It comes with fixes that regress back to bugs. It comes with dependency issues. It has sometimes problems with supporting different standards. I think you understand what I am talking about. All software has bugs and similar issues and our “production chains” are not different.
Most users may never notice a critical accessibility bug that blocks assistive technology users partially or totally. Sometimes we trust the tools too much and rely on them fully, but they can deceive us and make end products less accessible or even not accessible.
Browsers have bugs, some of them are critical for accessibility
Browsers, user agents or whatever you want to call them have bugs. No surprises there. But some browser bugs are also accessibility bugs and therefore maybe more important than other bugs.
I will not go into details or show a lot of history in this short post, but chances are you can find abundance of bug reports on browser repositories and follow the timelines and so on.
Just wanted to give a simple example: Adrian reports of Safari browser having problems with CSS display properties (opens in new window) that can make an innocent CSS code break accessibility. This kind of bugs can only be discovered if we can get the code and use screen-readers to test it. So if developers / quality assurance don’t test with screen-readers and their definition of done doesn’t include such tests or even tests with people with disabilities they can’t really know about it.
So we should really submit bug reports and also verify them (they are sometimes closed but not resolved).
Screen-readers have bugs too, and “features”
Screen-readers are software too. So yes, they also have bugs. Sometimes it’s on them and sometimes it’s the combination with the browser. But yes, there are probably bugs in both closed and open sourced screen-readers. It’s easy to find and report bugs in open sourced screen-readers, like for example NVDA (opens in new window).
In case of closed sourced screen-readers it’s sometimes more difficult, but it should not really be a problem. Especially with licenses and support in place. There are always priorities and it takes some time in both cases.
But yes, sometimes we need to go on the version level to test and verify code. So just consider this when you stumble on a problem next time.
Another interesting concept is that some screen-readers decided to interpret code differently from others. An example is Apple’s VoiceOver that can remove semantics from lists that use CSS to show the list with no bullets, for example (opens in new window). Quite a common pattern in navigation and still – CSS can also take away the list semantics.
I needed an input type range in a project and I tested my widget with screen-readers. All of them were working just fine except Talkback that didn’t respect the values I set but it just announced percents all the time. I will probably make another post with the details but I checked the Issue tracker and found somebody was already trying to report the bug in 2020 so I added my comment to it and it was actually resolved quite quickly. Please check the Talkback issue tracker about the bug that I helped to comment (opens in new window).
Automatic accessibility testing tools also have bugs
When I made my umbrella automatic testing tool aXeSiA, I noticed that some test were failing. It was bugging me and I decided to get into reasons. Some pages broke my testing process with mysterious messages. Digging into source code and setting breakpoints and even console.log’s I managed to discover the issue – it was a testing rule that had a bug. Luckily for me the bug was already reported and fixed and all I had to do was to wait for next release.
I was doing a check on a page that had two ARIA roles and it made me wonder why it was failing it as a WCAG failure (opens in new window). It was actually an axe feature based on old Internet Explorer issues and therefore in reality a bug (as IE is not supported anymore). So sometimes there are even features that become bugs. And even in auditing tools used by millions.
If your continuous delivery pipeline is automatically blocking releases based on some linters it may be a good idea to check the issues frequently, so that your pipeline doesn’t do more harm than good. That goes especially for larger organizations where pipelines are managed by people more distant to developers that release the code, I would guess. Getting such “false positives” may quickly mean that developer will just try to fix the code to satisfy the linter and with it potentially worsen accessibility.
Conclusion – please test more and report the bugs
I guess we have to share the responsibility if we want to make the field better. Testing is the first step. If we don’t test it may fall back on us when QA tests. If QA don’t test it properly it may be released and discriminate some users. We don’t want that. We want to make things accessible and we want to report the bugs so that they are fixed or that we implement an alternative solution and try to bypass the bug.
But let’s face it – all software can and probably also has bugs. It’s a reality. So please test and check before releasing it. As early as possible.
