This learning plan is designed to provide web developers who are accessibility beginners with a plan and actionable goals for the journey of learning. It provides focus and a timeline rather than aimlessly searching tutorials. I've copied the format from Anton Ball's Typescript Learning Plan.
Wikipedia does a great job of defining what a learning plan is.
The goal of the learning plan is not to teach accessibility but provide the plan and resources in order to learn. The plan has a clear stopping point - the scope is basic accessible web development skills. This plan does not cover app development, which uses different code and techniques, although the underlying principles are the same.
When you've completed the plan, you will be able to create basic accessible content and make a well-informed choice when reviewing more advanced plugins and tools which claim to be accessible.
A basic understanding of front-end web development is assumed.
These resources will be useful in this learning plan. There are many others which you may prefer. Suggestions welcome!
- Chrome Accessibility Tools (extension) and/or Firefox Accessibility Tool
- Lea Verou's Contrast Ratio tool or other contrast checking tool
- NVDA to be used on Firefox/Windows or VoiceOver on Safari/iOS or Safari/Mac
Accessibility is a property of all websites, web apps or software apps. Some are more accessible than others.
"Being accessible is about making your website, with all of its data and functions, available for anyone, no matter how they have to use your website." - Katie Cunningham, Accessibility Handbook (O’Reilly)
- What we mean when we talk about accessibility by Alastair Duggin for Gov.UK
- Google's Web Fundamentals: Accessibility Overview
- Web Accessibility Initiative at W3C: Introduction to Web Accessibility
(Times are wild guesstimates)
| Goal | Time | Task/Projects/Activities |
|---|---|---|
| Writing semantic HTML | One Day |
Writing semantic HTML makes all other accessible development techniques much easier. It is the foundation of your ability to write code which can be translated and transformed by the user and their chosen software into a format which works for their needs.
Activity: recreate a content-heavy page (try a page from Wikipedia or documentation of a framework you use) using semantic HTML. Use the MDN HTML element reference rather than the articles above if you need to find out what element to use. |
| Creating accessible styles | Half day |
Accessible designs are out of scope for this learning plan. But we need to know how to implement them using the right techniques.
Activity: make sure your content page is repsonsive and add focus styles to any links or buttons. Use a contrast ratio tool to check the page and make fixes if needed. Add body {filter : grayscale(100%);} to the CSS to check if you have relied on colour alone for any visual indicators, and fix any problems. |
| Making images accessible | Two hours |
Images often have some of the most useful information on a page. It's important to make sure that information is conveyed to all users, not just those with good vision.
Activity: find a website with a lot of images in content, like for an art gallery or a band website. Write out the alt text you'd use for each one, and why. Repeat for a web app which uses lots of icons on it's controls, like email or video services. |
| Learn the hiding methods | One hour |
Dynamic sites and common widgets let users show and hide chunks of content. The method you choose for hiding makes a big difference to how accessible your site is to keyboard and screen reader users.
Activity: Make a page with chunks of content, some with links or buttons in them. Experiment with HTML and CSS methods of hiding content. Compare the results in the browser, in dev tools, with a keyboard and with a screen reader. |
| Build an accessible drop-down menu | Half day |
Site navigation brings together accessibility requirements, so it makes a good practice feature.
Activity: create a flyout or dropdown menu. When you are done, compare it to the examples given by The A11y Project or Heydon Pickering's Inclusive Components. How would you make yours responsive? |
| Build an accessible form | Half day |
There's more to accessible forms than choosing semantic elements. We now have to use the right attributes, and consider how screen reader software behaves differently inside form elements.
Activity: Follow pages 1 to 4 of the WAI forms tutorial to make a short form using a variety of input types and groups. Make sure they are all labelled correctly, and provide information about required fields and instructions. (Error messaging is the next lesson!) |
| Providing accessible error messages | Half day |
Giving your users accessible error messages has a number of potential pitfalls to avoid. We want to make it as easy as possible for everyone to recover from any mistakes and finish their task.
Activity: Use pages 4 and 5 of the WAI forms tutorial to add validation and error messages to your form from last week. Test it with a screen reader, in high contrast, and on a small screen. |
| Quick and dirty testing | Two hours |
Quick testing is useful to confirm that the information you want to convey to all users is actually available to all users. It cannot replace a full audit by an accessibility specialist, or usability testing by people with disabilities. But you can check that your work is of good-enough quality to hand over for a proper quality assurance process.
Activity: perform these tests on the pages you've made during this learning plan. Use the resources linked in this plan (or Stack Overflow) to find solutions to any problems you come across. |