The simplest way to achieve a high standard for accessibility is simply to follow best practise HTML5.
In particular, I would recommend getting familiar with how the document outline is constructed for web pages from sectioning elements.
Don't make users on screenreaders have to tab all the way through your multi-tiered mega-dropdown to reach the page content they're looking for!
The first focusable element on the page should always be a Skip Link. This does not need to always be visible, however.
We want our HTML to be valid. Wave is a handy chrome plugin that will highlight some simple problems with your HTML. You should fix most errors, but take this report with a grain of salt (for example it seems to over-report heading issues aligned with the old HTML4 way)
Make sure the document outline presents a legible, sensible index for your page. This is important for screen readers and other indexing technologies that might access your page. To achieve this you should follow best practise for sectioning elements as you put the site together.
The HTML5 Outliner chrome plugin is useful for debugging this.
Initial colour checking is the responsibility of a designer and should have been done during visual design rollout. However, developers should always run a preliminary check to ensure nothing new has slipped through during the development process.
The Spectrum chrome extension can be used. This tests pages for the following visual conditions:
- Protanopia
- Protanomaly (red-green blindness)
- Deuteranopia
- Deuteranomaly
- Tritanopia
- Tritanomaly
- Achromatopsia
- Achromatically
- Low contrast screens
The Color Contrast Analyser chrome extension can be used. This runs a contrast test to ensure that all visual elements have sufficient contrast to pass AA conditions. Have patience, this can take some time to run.
Turn your screen off! MacOS Voiceover and JAWS (on the IE machine in the device lab) software is available for manual testing.
If you are not familiar with these tools, there is training available in MacOS for Voiceover which is worth completing, and WebAIM have a page outlining basic usage for JAWS that you can keep open.
When testing, pay special attention to sections, navs, form fields, or lists that may be missing visually-hidden headings or labels to enhance and add clarity for audio-only users. Also look out for large sections of content that are hidden but still read out, which may need to to be hidden from the screen reader as well (eg: a content modal or menu).
Also ensure that correct focus is given to dynamically-shown sections, and conversely taken away to somewhere logical when hiding these.
The page zoom is tested at 75%, 100%, 150% and 200% to check that the content still flows as expected, and is legible.
aXe dev tools can be installed on chrome to provide a final check for any further accessibility issues. This tool is very thorough and unlike the above tools is specifically tailored to catching accessibility issues, so is recommended to be run at the end after other basic issues are covered.
There are often no clear-cut right or wrong answers here; get creative and use common sense to ensure the page reads in a way that makes sense, and is easily navigable.
Accessibility is essentially just good UX design, so if you're stuck it can be helpful to talk to a UX or interaction designer to run through some ideas with. They will bring an outside perspective free from the constraints of technical challenges.
The web is always changing and we need to work together as a team to keep up with the newest technology and accessibility practices. Always do what you can to advocate for good accessibility and teach others — an inaccessible web is a discriminatory web.