Estimated reading time: ( words)
Summary: Web accessibility is not a compromise. Web accessibility is an opportunity to become better at what you do. Will you?
Web Content Accessibility Guidelines (WCAG) 2.0, level AA, serves as the web accessibility standard for the University of Minnesota.
Accessible web development: what does it mean?
From a coding perspective, the goal is to code a website or web application that, at minimum, meets Web Content Accessibility Guidelines (WCAG) 2.0 AA standards. Your website or web application should follow these four guiding principles of accessible technology:
- Perceivable - Users must be able to find every item using one of their senses.
- Operable - Users must be able to interact with the site and all of its features.
- Understandable - Content and functionality should be easy to follow.
- Robust - Sites should work with various technologies and consider future technologies.
More information about the POUR guiding principles (WebAIM).
Make accessibility part of the coding process
Coding for web accessibility can be intimidating. At first glance, the WCAG standards can seem confusing and complicated. In addition, it can be daunting to have to learn how to use different adaptive technologies like screen readers.
Fortunately, you can make the websites and applications you code accessible--or mostly accessible--by focusing on learning skills in just a handful of areas (see the "In This Section" panel on this page).
While always encouraged, testing your website or web application using a screen reader is not always necessary.
It isn't all about screen readers
We're coding to make information accessible by people who use any and all types of adapative technologies. Screen readers are but one example. Learn more about the different types of adaptive technologies, and consider the effect of accessible code on all of your potential users.
Write accessible code from the beginning
Accessibility should be incorporated as soon as you start to write code. Trying to retrofit your code for accessibility later on can lead to:
- Missed deadlines
- Never actually "getting around to it"
- Pressure to skip accessibility
- Re-coding and/or functionality redesign at the end of the project
- Missed accessibility features
While there is a learning curve at the beginning, it takes about the same amount of time to write accessible code as it does to write inaccessible code.
You should check for web accessibility frequently during development. View your websites and web apps in a browser to ensure they display and function correctly.
Browser plug-ins and tools can help you check for accessibility as you code.
Build in reminders
In the messy process to get a website or web application coded, it is easy to forget or forgo accessibility. We recommend these strategies:
- Create and use a developer checklist as you work. Example checklists:
- Make an accessibility statement as part of your code commit template.
- Make basic accessibility testing part of the QA or acceptance testing.
- Make accessibility a requirement by creating a user story for every project.
Accessibility doesn't compromise design
There is the misconception that making a website or web application accessible requires developers to not use more advanced user interface components. This is rarely true. Many modern user interface components are either accessible or can easily be modified to be accessible.
Start with an accessible template
To kickstart your project, copy from an existing template or similar project. Ensure that the items you start with are already accessible. Fortunately, frameworks like Bootstrap are starting to incorporate accessibility into their code, and more importantly, into their examples.
Many examples on the Web claim to be accessible but may not be, or they may follow a different, less rigorous standard. Always check the accessibility of code snippets, templates, and frameworks before you implement one into your project. Check out the U of M accessibility project on GitHub for more.