The end of the year is always a time for introspection and goal setting, and if you help make web applications inside or outside of work, then I have 7 very achievable resolutions you can consider for your year ahead.
1. Enhance your linting with an a11y plugin
2. Choose an extension to regularly check your code in-browser
3. Befriend your screen reader and learn at least 3 skills
4. Take a mouse/trackpad holiday
5. Audit your heading levels
6. Familiarise yourself with challenges presented by Single Page Applications
7. Change your definition of done
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 well 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 'alt' attributes for images, including checking for common quality issues in 'alt' text (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.
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 'alt' attributes
- 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.
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.
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 'tab' key
- The currently focused item should have a clear visual indicator (e.g. a blue border)
- Non-interactive items should never receive focus with the 'tab' key
- The order of where focused 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
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
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 'h1' element that clearly describes the purpose of the page
- Heading levels should then only increase by one at a time, e.g. 'h2' → 'h3'
Read some more detail about handling heading levels in this article: Getting Heading Levels Right
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 well have a huge benefit to the accessibility of your web apps.
Potential Pitfalls and Resources
- 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.
- 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 on DEV: Page Titles and A11y in Single Page Applications (esp React & Vue)
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 - 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!
About the Author
Suzanne is a Software Engineer based in Edinburgh, and the creator of Up Your A11y - a website collecting tutorials and tips for creating accessible web applications, particularly in React. You can also find her on the blogging platform, DEV.