We’ve been building a bi-lingual application for a public sector organisation in Wales. As part of the process we partnered with the Digital Accessibility Centre (DAC) to audit our code.
This audit was an important step for the client, and it proved a great learning experience for the development team at Toward. Accessibility is something we take very seriously but it can be difficult to get good advice about how to make more complex websites and applications accessible, and how to find and fix issues that are spotted.
There are lots of common and well understood accessibility issues (like using button elements for buttons, adding alt text to images etc). The DAC has a team of testers who all use assistive technology (AT) every day. They thoroughly audited our code and website, provided detailed feedback, and suggested fixes for issues we had either missed, misunderstood, or knew nothing about.
Below are some of the things we’ve learned by going through this process to help us and others not make those mistakes again.
Stuff we learnt, re-learnt, or re-thought
1. Make context explicit
Even with semantic valid HTML, visual context is not always obvious to users of assistive technology. For example, take a card which has a button to allow a user to edit the content. That button visually could be wrapped up in the card, with appropriate heading levels etc, but if that control only has the text “Manage” a user of AT is going to just find a bunch of random buttons without any context..
Instead add some specific screen reader only text, or an aria label to provide the context explicitly (e.g Manage (mega awesome card content))
2. Don’t use colour to show interactivity
Be careful when highlighting interactivity (think focus or hover states) only by colour. If outlines or offset borders fit your design and component use those instead. If you need to only use colour you need to consider contrast too. For example if a border colour or background changes but goes from a blue to a yellow, the change can be too subtle (or identical) for some users to notice.
3. Translations
The app we’re building is bi-lingual and allows users to add both English and Welsh translations for user created content. When we display a preview of the Welsh in the English version of the site, we didn’t realise we’d need to set the Lang attribute on the preview card. This was a bit of a head scratcher to achieve with Craft but Charlie figured it out.
4. Auto generated captions are garbage
Auto generated captions (renamed “craptions” by the community) are pretty ropey, especially with brand names, non US accents, or unusual terminology. I guess bad transcripts are better than none (please always include them - I never want to watch your video), but there is probably no substitute right now for having a human do these (or at least review and edit them).
5. Definition Lists are bad ass
One of my all time favourite under-used elements, DL elements were sighted in a couple of bits of feedback. Once you understand what they are and what they are for, you’ll use them all the time to display information.
6. Use aria-current=”page” for active state
I had never heard of this but essentially you want this attribute on any link or control you’d want highlighted as currently on.
7. GDPR banners first
If you are working in a GDPR affected area, your banners should be the FIRST thing in the HTML body. This is not necessarily obvious if your banner is at the bottom visually. If it’s not, it can mean users need to tab through all the content to say “No thanks” to all your (really important) cookies. Also unsighted users might never find it (or have it disrupt their browsing experience).
Special High Contrast Mode SVG section
I thought Windows High Contrast Mode (WHCM) deserved its own section. Although we were aware of it we (shamefully) didn’t know about these gotchas with SVGs
8. Make sure you use currentColor for fills
WHCM can make icons invisible if you’ve just put an arbitrary colour as the fill. Luckily WHCM has its own Media Query so you can target all icons and force the fill to the current text colour which should work all the time.
@media (prefers-contrast: more) {
.fill-current {
fill: currentColor;
}
}
9. Select drop down icons should use canvasText fill
Custom dropdown icons can be made equally invisible in WHCM. These are usually set as a background image though so the above fix won’t work here. The testing agency recommended setting the fill inline on the SVG to “canvasText”. This will:
“force the chevron icon to use the current default text colour. Outside of High Contrast Mode, the styling remains the same, as the default text colour is black. Within Windows High Contrast Mode, the icon will be filled in the text colour chosen by the user.”
10. Custom radio button and checkbox icons
In our design the off state still used check icons in a pale colour to help show the user that it was a checkbox (trust me in the design it worked). However in WHCM these pale ticks end up looking the same, checked or unchecked. The advice here is to not show the icon when its not checked to avoid confusion
Bugbears
The following are actually things we knew about already, but they are also bugbears of mine so I’m telling you because you are here…
11. Trap focus
When you have a modal popup it is important to manage focus correctly. This means in a modal ensuring that the user can’t tab out of the modal without closing it. There’s a bunch of other stuff you need to do too, like returning focus to the last element before you opened it, and focusing on the first item in the modal when it opens, but please do this.
12. Don’t hide labels. Ever.
It is lazy and annoying. It might look slightly cleaner from a design perspective but it makes it hard to use for some folks. Just make the design better so the labels look ok.
13. Date fields are garbage
The default HTML5 input type=date is not good. It is inconsistent across browsers, making it hard to validate anything. Just use 3 fields and deal with the design fall out. Gov.uk has some excellent guidance on this.
14. Don’t fix headers
Zoom your browser in by 400%. Done? Ok good! Now please tell me how important your sticky header is?
15. If you are gonna open a link in a new tab/window, tell the user please
Tell people you are opening a link in a new tab. You can add a little icon, or some text (opens in new tab). I know no one likes this when I tell them, but a link opening in the same tab is THE DEFAULT BEHAVIOUR OF EVERY BROWSER EVER. Therefore, if you are going to subvert the default, let people know.
16. Articles are everywhere
Use article elements for more stuff, particularly cards. Often these are misunderstood to just be for articles in the blog/news post sense. They are actually a lot more versatile—like a more semantic div that helps group the contents. This advice solved this issue for us:
“Although arranged by headings, the link cards do not programmatically group or contain their content. This could make it difficult for screen reader users to understand where one card ends and another card begins.”
Wrap up
I think we’ve all learned a lot of important lessons today. If you are a developer or designer, and you’d like to learn some more, I’d recommend working with DAC on your next project. If you aren’t a developer or designer but accessibility is important to you, you should hire us to build your next thing.
