Workshop on Accessibility
In this workshop we will attempt to put into practice this finding (Mankoff et al):
“Multiple evaluators using a combination of a screen reader and monitor were most consistently effective at finding both empirical and WCAG accessibility problems.”
Getting set up
“Multiple evaluators”
Developers sometimes find it helpful to pair up with each other while they are writing code. Optimistically, “pair programming” offers:
half the feeling of banging your head against the machine
double the chances of getting unstuck quickly
one person can look up something while the other writes code
you might learn new coding patterns because their brain is different from yours
So, we will ask you go get into pairs.
INFO
You will also be able to submit the homework together with your partner. You’ll only have to submit one website, and it will give you both credit.
“Screen reader and monitor”
Try to form pairs where:
At least one person in each pair will have headphones they can listen to and a computer with a screen reader on it. Common ones include NVDA, Apple Voiceover, and JAWS (costs money).
At least one person will have a screen they can inspect visually
Finally, because automatic tools have improved a lot since 2005, when the Mankoff study was done, at least one person will have a browser tool or plugin that checks accessibility. Common ones include WAVE, Lighthouse, and Axe (costs money).
Improve the design of an inaccessible website
Your main workshop task is to improve the accessibility of “Medical Mysteries Club”, a fake landing page created by web.dev and made intentionally inaccessible.
Download the starter code from GitHub:
github.com/Birkbeck2/web-development-accessibility.
You can download it as a zip file or create a repository from the template (requires Git / GitHub knowledge).
Unzip or extract the files from the zip and open them in your editor.
Check it with automatic tools
- As a first step, please run an automatic accessibility checker. Modify the HTML or CSS to bring it up to accessible design standards.
INFO
The homework autograder for this session uses a free CLI version of Axe, so you can submit a working version of the homework on Gradescope.eu to see Axe errors.
Check it with mainstream technology
- Once your checker is returning a good score, try manually inspecting the page, comparing it against what you know of WCAG, accessible design patterns from the lecture, semantic HTML, and responsive CSS. Are there any further improvements you can make?
Check it with assistive technology
- Finally, please examine it using a screen reader. What do you notice about the usability that you missed with the checker and mainstream tech inspection?
Expand the form
In the second part of the workshop, you’re asked to expand the form from a subscription form into a contact form.
Add fields for first name, last name, email address, and message, and change the text on the submit button to something like “Send”.
Please make sure your form meets these requirements:
Specify a form method.
Choose the appropriate HTML elements and attributes for each piece of information in the form.
Give each input an appropriate name to serve as the variable name for the data.
Make sure each input has a label that is fully accessible.
Include a button for submitting the form with the appropriate markup.
References
Fisher, Carie, Alexandra White, and Rachel Andrew. “Learn Accessibility.” web.dev. Accessed November 14, 2023. https://web.dev/learn/accessibility.
Mankoff, Jennifer, Holly Fait, and Tu Tran. “Is Your Web Page Accessible? A Comparative Study of Methods for Assessing Web Page Accessibility for the Blind.” In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, 41–50. CHI ’05. New York, NY, USA: Association for Computing Machinery, 2005. https://doi.org/10.1145/1054972.1054979.