This post was originally shared via the Ladies of Code Advent Calendar
The start of a new year is often a time for introspection and goal setting, and if you help make web applications inside or outside of work, then I have 7 resolutions for your consideration.
These very achievable goals will help you retune your approach to web development, putting accessibility considerations at the heart of it.
The 7 resolutions in this post will cover:
- Enhance your linting with an a11y plugin
- Choose an extension to regularly check your code in-browser
- Befriend your screen reader and learn at least these 3 skills
- Take a mouse/trackpad holiday
- Audit your heading levels
- Familiarise yourself with challenges presented by Single Page Applications
- Change your definition of done
1. Integrate A11y-Linting Into Your Project
If you are working in front-end development, chances are you already use ESLint in your project. It's a great tool to make sure common code errors are picked up as early as possible, and way before they are pushed to production.
Additional plugins can help lint for accessibility issues, and one great tool is elsint-plugin-jsx-a11y. This checks for common accessibility issues that can be picked up by a linter, for example:
- Making sure form inputs have appropriate labels and IDs
- Appropriate
altattributes for images, including checking for common quality issues inalttext (like redundant use of words like "Image of...") - Inappropriate use of
tabIndex
Using the jsx-a11y plugin lets you introduce a safety net, catching code issues before you even have to look at the browser. As with your other ESLint rules, you can also set up your CI pipeline to fail if issues aren't addressed and it can help you save time looking for these kind of errors in code review.
2. Choose an Extension for Checking Your Code in the Browser
Lots of accessibility issues can be picked up by browser extensions, and not only will the issue be highlighted clearly on the page, but they usually can suggest ways for you to fix the problem!
These tools are especially great for accessibility issues like:
- Ensuring sufficient colour contrast
- Making sure images all have
altattributes - Verifying heading levels and semantic HTML have been used appropriately
The most popular tools are Axe and WAVE. Both are excellent - try them both and see what you prefer!
Check in with them before pushing any code up for review, and you will already start making accessibility checks a more integral part of your workflow.
3. Make Friends with Your Screen Reader
Becoming comfortable with how a screen reader works, and how users commonly browse the web with them is essential to properly considering accessibility in your overall development approach.
Which Screen Reader
Based on the latest WebAIM Screen Reader User Survey, these free options will work well:
- Mac users can simply use the built-in VoiceOver (switched on and off with
cmd+F5) - Windows users can download and use NVDA
The Basics to Learn
As a basic starting point, learn to do the following with your screen reader of choice:
- Read and step through a page of content - this will help you check sections of your page and how they are announced to screen reader users
- Scan through heading levels - this is essential given the majority of screen reader users will "scan" your content in this way before stepping into a given section
- Tab through interactive items - this is standard keyboard navigation, but get comfortable in doing this with your screen reader switched on, and interacting with those items as you do so (e.g. clicking buttons and links)
Getting more comfortable with your screen reader, and checking your code regularly with it will help you to naturally consider "How will this work with a screen reader?" when picking up a piece of work.
If you use a Mac, you might find my previous post on this helpful:
4. Take a Holiday From Your Mouse/Trackpad
Similar to Step 3, get comfortable on how users navigate the web with the keyboard. Some key things to know:
- You should be able to move through all interactive items on the page (buttons, links, form inputs, etc) using only the
tabkey - The currently focused item should have a clear visual indicator (e.g. a blue border)
- Non-interactive items should never receive focus with the
tabkey - The order of where focus is placed as you tab through the page should make sense. Usually this means it follows the order you would expect as a sighted user (e.g. top to bottom) and not jump around randomly
For a bit more detail, check out this post:
Regular checks of your work using keyboard navigation only will help flag accessibility issues such as:
- HTML elements being declared in a non-logical order (causing the tab order to not flow in a logical progression)
- Interactive items not receiving focus (e.g. a custom component like a Card that a user should be able to click)
- Default focused states being removed for branding/design reasons, but never replaced
5. Audit Your Heading Levels
As highlighted in Step 3, screen reader users utilise heading levels to be able to scan and skim your content, in a very similar way to how sighted users do. A quick audit of your heading levels can make a big difference and help surface useful content to a broader range of users.
Some quick rules:
- Every page should have a
h1element that clearly describes the purpose of the page - Heading levels should then only increase by one at a time, e.g.
h2→h3
Find out some more detail about handling heading levels in this post:
6. Understand the Potential Issues in Single Page Applications
This is a large topic in itself, but if you work with a framework that utilises client-side rendering such as React or Vue, becoming familiar with these potential pitfalls will have a huge benefit to the accessibility of your web apps.
Potential Pitfalls and Resources
Route changes:
- When a route is changed in a client-rendered app, screen reader users are often unaware the page content has changed and may be "lost"
- If a user clicks a link that results in a client-rendered route change, often the focus is left on the link which is no longer visible, which can be very confusing!
You can find some further exploration and approaches to correct this on Up Your A11y: Handling Focus on Route Change in React.
Page titles:
- In a Single Page Application, the page title never changes unless it is explicitly managed. This isn't very helpful to screen reader users who may have several tabs or windows open and want to know what page they are currently on.
You can find some exploration and tips on how to handle this in my previous post:
7. Change Your Definition of Done
This last step is perhaps the most important - before you push to code review:
- Check in with your ESLint, configured for a11y checks, and correct any errors
- Run your work through one of the in-browser verification tools mentioned above - are there any issues that need fixed?
- Switch on your screen reader and give it a quick pass over, including scanning by heading levels
- Tab through the content you just created - does it behave as expected?
- If your work triggers route changes in a Single Page Application - double check that the route changes have been handled with accessibility in mind
If you complete these steps as often as possible in your work, you are well on track to creating accessible web applications in 2020!
Did you find this post useful? Please consider buying me a coffee so I can keep making content 🙂
Top comments (6)
Thanks, Suzanne (fellow Scot here). I'm just getting into developing and the concept of accessibility and I'm going to make sure I implement these ideas when I build my freecodecamp portfolio site in the next week.
That's amazing! Considering accessibility from the outset will definitely put you on a good path for your site 😁
Hopefully see you around the Scottish tech scene soon!
This is a really good article. Thank you _.
Thank you ♥️
Really great article, thanks.
Thank you and thank you for taking the time to read it 🙏