This article starts the module off with a good look at what accessibility is — this overview includes what groups of people we need to consider and why, what tools different people use to interact with the web, and how we can make accessibility part of our web development workflow.
|Prerequisites:||Basic computer literacy, a basic understanding of HTML and CSS.|
|Objective:||To gain familiarity with accessibility, including what it is, and how it affects you as a web developer.|
So what is accessibility?
Accessibility is the practice of making your websites usable by as many people as possible. We traditionally think of this as being about people with disabilities, but the practice of making sites accessible also benefits other groups such as those using mobile devices, or those with slow network connections.
You might also think of accessibility as treating everyone the same, and giving them equal opportunities, no matter what their ability or circumstances. Just as it is wrong to exclude someone from a physical building because they are in a wheelchair (modern public buildings generally have wheelchair ramps or elevators), it is also not right to exclude someone from a website because they have a visual impairment. We are all different, but we are all human, and therefore have the same human rights.
Accessibility is the right thing to do. Providing accessible sites is part of the law in some countries, which can open up some significant markets that otherwise would not be able to use your services or buy your products.
Building accessible sites benefit everyone:
Semantic HTML, which improves accessibility, also improves SEO, making your site more findable.
Caring about accessibility demonstrates good ethics and morals, which improves your public image.
Other good practices that improve accessibility also make your site more usable by other groups, such as mobile phone users or those on low network speed. In fact, everyone can benefit from many such improvements.
Did we mention it is also the law in some places?
Implementing accessibility into your project
A common accessibility myth is that accessibility is an expensive “added extra” to implement on a project. This myth actually can be true if either:
You are trying to “retrofit” accessibility onto an existing website that has significant accessibility issues.
You have only started to consider accessibility and uncovered related issues in the late stages of a project.
If however, you consider accessibility from the start of a project, the cost of making most content accessible should be fairly minimal.
When planning your project, factor accessibility testing into your testing regime, just like testing for any other important target audience segment (e.g., target desktop or mobile browsers). Test early and often, ideally running automated tests to pick up on programmatically detectable missing features (such as missing image alternative text or bad link text — see Element relationships and context) and doing some testing with disabled user groups to see how well more complex site features work for them.