Accessibility Principles - aduggin/accessibility-notes GitHub Wiki
Draft principles
1. Consider accessibility from the start of service design
Only considering accessibility late in a services design and implementation is likely to result in many barriers that will exclude people with impairments from using your service. Fixing issues late in a project is always more difficult and costly. Identifying them early enables you to design a better solution for everyone and is cheaper and more efficient to deliver.
2. Aim for simplicity and consistency
Complex interfaces are harder to implement (and therefore more expensive) and also exclude many users that have low digital skills, cognitive impairments and those using assistive technologies such as screen readers and speech recognition software. Consistent interfaces help people to learn, use and understand them.
Make your service look consistent with the rest of GOV.UK by following the GOV.UK Elements, the government design style guide
3. Ensure content is clear, succinct and easy to understand
This will benefit users with cognitive impairments such as the 10% of the population that has dyslexia. It also benefits user that have English as a second language or the 7 million adults in the UK with a reading age less than 11 years old.
Follow the GOV.UK content guidance
4. Accommodate a range of needs by providing choice and flexibility
Provide multiple ways for people to get content and for them to provide information.
5. Provide equal access irrespective of human capability
Ensure that disabled people can perceive, understand, navigate and interact with content equally without barriers
6. Include people with impairments in the user research, design and testing of your service
A service that works for people with impairments will result in a more usable, flexible and accommodating service for everyone. You have limited time and resources for usability testing. You are much more likely to find usability issues by testing with people that are more likely to struggle with your service than by testing with users with a limited range of capability.
7. Ensure the online parts of your service Aim meet level AA of the Web Content Accessibility Guidelines (WCAG 2.0)
By following and complying with WCAG, a set of inclusive design best practices, the online parts of a service is likely to work for much larger audience, including people with vision, hearing, cognitive and physical impairments. The WCAG are an international standard that has been created by accessibility experts with input from people with disabilities.
8. Test the online parts of your service for compatibility with the most common assistive technologies
The only way that you can be confident that a service is compatible with assistive technologies is to test them and to fix any issues that are in your control
Checklist Notes
- Consider accessibility from the start
- Keep things simple, consistent and intuitive
- Use plain English - clear, simple, succinct and easy to understand
- Break text into chunks - using headings, short paragraphs and links
- Make text legible
- Allow people to customise how it looks
- Don't communicate by colour alone
- Ensure all visual media has a text alternative that communicates the same information
- Provide captions and text transcripts for video
- Use the most appropriate HTML elements
- Ensure forms follow best practice (content, design and code)
- Ensure dynamic content works for all users
- Pick the most accessible format (HTML over PDF where possible)
- Make sure it works with all input devices (mouse, keyboard, touch, voice input)
- Make sure it works in a range of assistive technologies (screen reader, screen magnifier, speech recognition, literacy software and custom settings in a browser)
- People may require alternative formats (large print, audio, braille, BSL, Easy Read)
- Ensure people have a choice of communication channels (Phone, text, BSL)
- Confirm that it meets accessibility best practice (WCAG 2.0 AA)
- Watch people with a range of abilities use it