There are some web accessibility issues that have their origins in design, for example poor contrast and forms with no labels and so on but quite often there are also some issues that are caused by developers. I’ll try to discuss some that I stumbled upon recently.
Using pixel (static) units for everything
I’ve done it myself, before I understood the consequences – got a design, it was in pixels, and wrote it in HTML with CSS, everything in pixels. Everybody was happy, maybe I had to use some media queries to have different pixels for different screen-sizes and that was it. Designer happy, QA happy, client happy, user happy, right?
When I learned more about accessibility and it’s best practices I stumbled upon problems with static units being used for everything; they can often cause a lot of damage for groups of users that wanted to use larger fonts, for example. Fixing fonts, element heights, text line heights and so on can prevent custom settings coming from users browser. Some users prefer to have larger fonts on all pages and therefore they can set custom font sizes on the browser or operating system levels. Setting pixels can prevent their settings to work and they end up with a problem.
I don’t know why this is not common best practice but all web developers should learn this when they get to know CSS – please use em or rem units and also be sure to test that designs will not break when browser font is enlarged / page is zoomed in. WCAG technique for Success Criterion 1.4.4 – Resize text (opens in new window) is discussing this and I recommend we start using em/rem/ or any other suitable dynamic unit to make things simpler and conforming.
Links that “do” things and don’t “go” anywhere
I’ve done it myself – you have a navigation and it has a search icon that expands the search field with it’s submit button. As it is in navigation we’ll just use anchor, right? We will just use href=”javascript:void(0)” or maybe even href=”#” or even no href attribute at all and fix the toggling with JavaScript, right?
Wrong! This is done quite often but let me explain that it has multiple issues. First one is that links should link – so lead somewhere – not “do” some action. Expanding/collapsing is an action, so we should really be using a button. By the way – not using href attribute also breaks keyboard interaction that is built in automatically, so please do use it on links that are links and use buttons if you do not need href or if href is not linking anywhere.
Everything can be done with a div and span element
Div and span has no semantics. They are block and inline HTML elements that can be used for presentation and although you can build everything with them it will not work for all users.
There are approximately 110 native HTML elements (opens in new window) that are available in HTML5 at the time of writing, and besides div and span they are semantic, which means that they bear meaning. Using semantic elements properly makes our products much more friendly, not only to browsers but also to search engines and assistive technologies.
Some users, for example, prefer to read articles with no noise – just the article and not all the aside information. They can use so called reading view and it will actually just show them the content in main HTML element.
Screen-reader users do not tag through the page to find content they want to find. They have abundance of possibilities – for example listing all links, headings, sections, lists, buttons and so on. Moving directly to footer, search, navigation with some keyboard shortcuts when using desktop screen-readers or selecting them with different screen-reader menus in mobile screen-readers make them very effective. But only if website was using semantic elements in the first place. So please learn and use them.
Everything can really be done with div and span, but it really shouldn’t. We have way better HTML elements available and they also come with plenty of accessibility features out of the box, especially keyboard interactions and states, so please use them to make better products.
Expand/collapse missing correct ARIA tags
Expand/collapse pattern is quite common – all from mobile navigations that only appear when clicking the so called hamburger menu to different kind of accordions, tooltips and so on. They are quite a standard from the early days of so called DHTML times on and nothing new on the web. Still, they are quite often missing important parts like semantics and their state.
This means that a developer can make a dynamic component, like for example hamburger menu that toggles list of navigation links that can be hard to use for blind screen-reader users. Sighted users don’t have a problem to see the expanding/visible navigation at once but for a blind screen-reader user it can be a bit challenging to move to navigation if it is for example not a direct sibling.
That’s why we can and should use aria-expanded and aria-controls, to “connect” the trigger button with the expandable / toggling navigation list. It’s a matter of some additional JavaScript and an ID and that’s it. Referring to WAI-ARIA practices (opens in new window).
Incorrect ARIA attributes or their combinations
When developers first learn about ARIA it can quickly become their first choice to make products more accessible. While ARIA can really be used to make advanced widgets it must first be understood. Sometimes we may remember wrong attribute for the job we want it to accomplish, sometimes we may forget that some ARIA attributes need sibling ARIA attributes to work and sometimes our IDE is allowing us to type ARIA wrongly altogether.
Remedy for this is simple – learn about ARIA, learn about five rules of ARIA (opens in new window), check if ARIA you need is actually supported (open in new window) and use IDE tools that help you with ARIA.
Not grouping related form controls
Forms can quite often be under engineered and I will not go into all the details, but not grouping related form controls is quite a common fail. Having multiple form fields that belong together can be simply grouped by for example fieldset and a legend HTML element but it’s often forgotten.
It may even be designed correctly, but not coded semantically, and I’ve noticed this so often that I decided to add it here. Please read about common best practices and patterns for forms in general and please group your radio buttons, checkboxes and all other fields that belong together with using fieldset element and a legend (opens in new window).
Ignoring keyboard interactions
It is actually a bit strange how often keyboard interactions get overseen. Almost every developer I know loves the keyboard shortcuts. They make our work more effective and faster. The same goes for using websites. But is often neglected.
I am guessing that developers forget about groups of people that can or don’t like to use mouse or touch to interact with pages. And not only developers but also designers and quality assurance. Using mouse and touch has become so common that keyboard is often left behind and it can cause barriers for people with disabilities that rely on their key(board)s alone.
So please – consider keyboard interactions and please also consider established patterns for it. Don’t re-invent but use common patterns. WAI-ARIA practices can again be used as a good source (opens in new window) and maybe you can sometimes even intentionally disconnect your mouse/trackpad etc. and work with keyboard alone, to really understand the importance of keyboard interactions.
Not wanting to learn basic skills of screen-readers
I get it – short deadlines, a lot of things to fix, still having to deal with cross-browser issues and so on – it doesn’t give us a lot of time to also test with screen-readers. And “for our product we don’t need to support blind users” quotes does not help. I get it.
I will not say that you have to be a super user of screen-readers, and I will not say that you need to test everything with a screen-reader. I will say though that every developer should be able to have some basic screen-reader skills to test the more advanced widgets before introducing technical debt. I do not see value in testing everything all the time with a screen-reader. It may even introduce unneeded coding work because of misunderstanding the screen-reader possibilities. Or it may mean that we would try to optimize pronunciations and other details and use a lot of time to fix something that screen-reader users are already accustomed to.
But checking new interaction patterns with screen-reader can potentially prevent deploying a problem. Testing with basic screen-reader skills can cause we need some answers from accessibility experts and people with disabilities before we can release it to production. So – I would not test obvious things with screen-reader. They will work as long as we used correct code and patterns. I would test the not-so-common patterns and new interaction implementations to check if they introduce new barriers. Ideally together with a team where also designers are present. Because it is again a team effort.
