DO NOT push to production without checking these things
Web accessibility is important. (If you don’t believe me I wrote this blog post to convince you!) Here are 5 simple checks that there are no excuses for not doing. Do not push to production until you can check off every one of these!
1. Look at the HTML of your page
Are the headings in the correct order?
This is often easy to get wrong, particularly if you are using components that dictate the heading level. Make sure that you only have one h1 on your page and it holds the most important information for your page. This will help somebody accessing your site via a screen reader to navigate your page. It will help you ensure that you can get the information of your site across as clearly as possible if the user doesn’t have the visual cues of your page available.
Are you using the correct landmark for your main content as opposed to a page full of divs?
In development it’s often easy to build and style with divs, just remember to come back later and make sure you are using the correct html landmarks. Familiarise yourself with this list. This helps anyone who can’t see your page, navigate the content of your page.
2. Keyboard controls
Can you tab through the whole page?
Try it! You should make sure every single interactive element is tabable — including modals, media controls, forms, links, buttons, drop downs etc.
Does the page have a logical tab order?
Every time you press tab, you should be able to guess where the tab should go next.
Does every tab have a clear focus state so you can see where you are on the page?
It should be immediately obvious where you are tabbed on the page.
3. Meta information
Check the primary title is descriptive
We’ve all been there when we’ve had hundreds of tabs open — the clearer the page title, the easier it is to find the content that you are looking for. The page title is the first thing to be announced on page load so it is useful for screen readers to have a clear understanding of what information to expect on that page from the get go. You also get bonus SEO points for making this check!
Define a primary language
Screen readers use the primary language to help with pronunciation — imagine how annoying it would be listening to a screen reader that is trying to pronounce in the wrong language!
In addition, if you need to use a dictionary and you highlight a word to look it up, it’s helpful to know what language of dictionary to search in.
4. Images
Ensure every piece of non text content has a descriptive tag
This should be easy enough to check. Look at your page as a whole and make a list of every item of non-text content. Include:
- images
- logos
- diagrams
- infographics…
Then find it in your HTML and check for a tag. While you’re checking, ensure those tags are succinct and useful.
5. Forms
Form fields should also be clearly labelled
It should be clear what information each field requires. For example if you mean “First Name”, label as “first name” and not “name” to ensure your user puts “Charlotte” and not “Charlotte Qazi”, particularly if you then ask for their “surname” in your next field. Not making this clear will be as frustrating for your user as it will be for your database when you’re pulling data that welcomes your user as “Hello Charlotte Qazi Qazi”!
Use error messages
Error messages should be used so it is clear why your form can not be submitted (as opposed to simply just ‘not working!’). They should also provide useful information on how you fix the error. For example “date should be formatted dd/mm/yyyy”. Make sure error messages disappear once the error is corrected to avoid further confusion.
Make it clear when the form has been submitted
Imagine how irritating it is for your user if they don’t know their input has been submitted and they keep trying to resubmit the form! Not to mention the effect this will have on your database! Bonus points if you also show the user the inputs they are about to submit with the option to edit them before the form is submitted!
Bonus points!
- Use a web accessibility evaluation tool to audit how accessible your page is. My recommendations are Lighthouse, or WAVE.
- You might consider installing an accessibility checking tool. My favourite is React Axe which shows any accessibility issues in the console and explains how to fix them. Simply install it and don’t ignore it’s warnings!
Further Reading
EDX: Introduction to Accessibility — This course is a fantastic and practical guide — if you don’t have time for all of it, modules 1 and 4 are particularly useful
Developing for Web Accessibility
