Writing front-end code that is accessible, can be quite time-consuming. We feel it is always worth the extra time and effort but sometimes clients don’t understand why it takes so long because they don’t know fully understand all of the elements that go into it.
This article will cover:
- Keyboard-only users
- Screenreader users
- Colours and contrast
- Font sizes and users who zoom
Keyboard-only users
Not everyone can use a mouse to point and click their way around a website and in that case, a person may make use solely of their keyboard.
With that in mind, an important feature of any website is to allow users to tab on their keyboard/device in order to move from link to link or from one form element to the next form element.
This poses two problems:
- Are all your elements tabbable?
- Is it obvious which element is currently active (in focus)?
Inactive links/buttons
Some elements on your site may be hidden from view, a good example is a hamburger menu in its inactive state. When the user starts to tab throuhg the site, should they be able to tab to hidden links in your hamburger menu? The answer is probably not because it is confusing.
Wrong elements used
Some developers may use the wrong element for a link/button and that element may not be able to be focussed by a keyboard user. If your 'buy now' button is not a button in your code then someone using a keyboard may never be able to press it.
Active links/buttons
A key feature of accessibility for keyboard users is the focus ring around actively focussed links/buttons. A lot of designers (and clients too) do not like this feature and ask to have it removed but, this can have a big impact on a site’s accessibility. If you are using your keyboard to tab around a website you need to know where you’re up to or else it becomes very difficult/annoying very fast.
The reason why a lot of designers do not like the default focus style (on Chrome and Safari, it’s a hazy blue halo) is because it appears for everyone, and not just keyboard users. Unfortuantely, as of this article, there is no 100% reliable way to mitigate that in every major browser, but there is a fix on the way with CSS called :focus-visible.
Screenreader users
When we first starting having our development work audited by third-party accessibility consultants a few years ago we learnt a lot about who uses screenreaders. A screenreader, reads out what is written on the screen. So far, so simple. The common logic is that only blind people use screenreaders, but the reality is that people of all different levels of visual impairment use them. This includes people who are completely blind, through to people with perfect vision.
Maybe a person with dyslexia would want/need to have the words on their screen read out loud to double check them and maybe someone with less than perfect vision might need extra help too. Don’t forget, to be registered blind does not mean that you have zero vision.
So if a user who has some vision may also have their screen read to them, that gives us a huge challenge. It means everything visually seen on the screen should be read out and anything that is read out should be visually seen on the screen. Elements must appear in the same order on screen as they appear in the code so that they are read aloud in in such a way to limit confusion. This means we cannot have left-to-right designed columns A & B swap around on the mobile version of our site using CSS so that B is above A in a stacked layout.
Single Page Apps (SPAs)
The concept of websites that behave like web apps (eg SPAs) give us a new challenge. If clicking a link only makes it look like the page has changed when actually JavaScript has taken over and updated our page with new content, then how does the screen reader know about it? How does our user know where the new content is?
This is also true of design elements like accordions or hamburger menus; when they are hidden or shown the screen reader (and therefore the user) may need to be alerted and sometimes the user needs to have their screenreader repointed to the new content so it starts to read out that new content.
Screenreader versions and updates
An important thing to note with screenreaders is that:
- there’s lots of different brands
- they can be very expensive, so users don’t always update them very often
This means there can be lots of little quirks with older, less popular screenreaders which are very difficult to debug for web developers.
Colours and contrast
Strictly speaking colours and contrast should be sorted at the design phase. Colours can be tweaked during development but clients may not think kindly to their brand colours being changed to meet WCAG standards.
A lot more people are colourblind than you may realise and a lot more people struggle with low contrast between text and background colours. If people can’t read the BUY NOW text on your big red buy button then they won’t click/tap it and you could lose a sale.
The colour contrast checker from WebAim allows you to quickly test your foreground and background colours to see if the ratio is high enough.
There are different rules and recommendations regarding 'normal text' and large text'. If the text is deemed to be 'large' then you get a little more room to manoeuvre in your colour choices.
Font sizes and users who zoom
Some users need a little help with text size. We would always recommend a minimum font size of 14px or even 16px for all copy on your site but even then this may not be enough for some people.
In those case, people may zoom in your site… or they may even change their browser’s defualt font size to be larger than the standard 16px.
Websites need to be built so that their layouts do not break when the user zooms in up to 200% of the original size in their browser. Most of the time it is sensible to revert to the mobile version of the site at this level of zoom.
Minimum font sizes in form elements on iOS
We often have to remind designers that on iOS (that is, iPhones and iPads) if a font size of less than 16px is used on a form element e.g. a text entry box or drop down then iOS zooms in the Safari browser when the user taps into the input field so the text is fully legible.
Annoyingly, when the user taps out again, it does not reset the zoom and a lot of users then get stuck with a zoomed-in version of your site which they find difficult to use.
There are workarounds but they are messy and are not advised by us.
Next
In our next article we cover how to code accessible websites.