The Importance of Accessibility in Web Design

The importance of accessibility has shaped web design since the very beginning. When Berners-Lee created the Web, accessible pages were part of his original vision. Accessibility isn't just about people with disabilities; it's about everyone getting the full value of every page they visit. Yet developers see it in very different ways, because it isn't ingrained in everyone. Some treat it as just adding alt tags. Others bolt it on as an afterthought. Many barely consider it at all.

Many people don't realise the importance of accessibility when building websites, and that accessibility matters from the very first line of code. It also supports the long-term vision of a well-constructed site. People with vision problems, for example, often face extra obstacles online. This limits the information, entertainment and social interaction the web offers them. Should they not enjoy your site as much as someone who can see fine? Is your website not there for everyone to enjoy?

The Web Was Built for Everyone

The web was designed for everyone. Without a mouse connected to your PC, you should still navigate a site almost as easily as if you had one. Even if you are completely blind, you should still get all the information you need from a page. The web was explicitly designed so that this could be done without any problems. Everyone viewing a site should be able to reach, perceive, operate and understand the content on screen, which is exactly why the importance of accessibility was baked into the web from the start.

Key Accessibility Issues to Fix First

Accessibility isn't just for the blind or disabled, and this is a common mistake to make when thinking about accessibility. An accessible site helps blind people read it and disabled people navigate it. A fully accessible site also boosts overall usability dramatically. Much of the accessibility work centres on providing for blind users. Because of this, the importance of accessibility is sometimes narrowed down to serving only the blind. Blind people do use the Internet, though. They need alternative text so screen readers can pick up images, plus proper page headings throughout.

Some designers still believe accessible sites must be dull or boring. This is a myth left over from the early days of web design. Older accessible sites looked dull for two reasons: the limitations of accessibility at the time, and the limited time and resources companies invested. CSS is far more advanced now. You can easily make a fully accessible site look as good as one built purely for appearance.

Alt Tags: The Simplest Accessibility Win

The most commonly known accessible feature is the use of the 'alt tag on images. Adding an 'alt' tag to an image, when used correctly, can go a surprisingly long way toward making a site accessible. Blind users can't see an image, but the 'alt' tag tells them it exists and what it shows. Use the tag correctly so blind people don't miss out on what everyone else sees. Just having an 'alt' tag isn't enough, it's there to say what the image actually is so that everyone knows. Small details like this are where the importance of accessibility really shows in day-to-day work.

Relative Font Sizes and Readable Text

Relative font sizes help many people. Remember that older and partially sighted users browse the web too, and they may rely on large text and strong colour contrast. Relative sizes like ems (the height of an element's font) or keyword sizes (xx-small through xx-large) let users adjust font size in their browser. They can then set text to a size they can actually read. Even so, many sites still use px, an absolute value, for fonts. Some browsers can't enlarge it. On a responsive site, px font sizes aren't really a problem anymore. Modern browser zoom works, reflowing the page as your responsive stylesheet dictates. Older browsers like Internet Explorer 6 (yes, some people still use it), 7 and 8 handle stylesheets oddly. Zooming just magnifies the page, so some pages end up with horizontal and vertical scrolling, which is not good. Some argue that developers shouldn't cater for old browsers, and there are good reasons for that view. It all depends on whether you're okay with alienating users that still use majorly outdated web browsers.

Developers once used tables to lay out websites. This was awful from an accessibility point of view. The good news is that developers have moved away from table-based layouts. Stylesheets and browsers now give us better ways to lay out a page. The bad news is that tables were misused for so long. Some developers now avoid them even when tables are the right choice. I've seen some developers questioning why a framework is using tables to display data instead of divs. Tabular data should be displayed in tables. If tables are used correctly, then there's nothing wrong with them at all, and they can even be responsive. Used correctly, tables are very accessible. It's concerning that some developers push tabular data into divs because they wrongly think tables should never be used.

How HTML5 Improves Accessibility

When coding a few years ago, to be accessible, it used to be a pain. The introduction of HTML5 has improved this drastically. HTML4 improved tables greatly. The <thead> and <tbody> tags clearly separated a table's header and body, and this helped with styling too. HTML5 takes tags to a new level of accessibility. Used properly, it gives people who need an accessible site a much better experience, and it makes the importance of accessibility far easier to honour in practice. This is one reason some developers won't build for older browsers like IE6-9. There, you must add extra work just to make HTML5 tags behave, and even then it isn't as accessible as on a modern browser. The argument is that users should keep up with modern browsers. Accessibility has improved so much that they'll get a far better experience.

HTML5 brought in some great new tags with semantic meaning. The problem is that Internet Explorer is still so far behind with it. Semantic elements such as <article>, <header>, <footer>, <nav> and <section> each carry clear meaning. That's great for anyone who relies on assistive technology (AT) to browse. Using IE though gives you no semantic data at all. On Firefox, Chrome, or Safari for OSX/iOS, a screen reader user can typically navigate to each of these elements. The browser identifies them clearly. This is because the semantics of the elements are exposed via the accessibility APIs in the browser. IE does not expose this information, so typically the information is not conveyed to users. Basically, IE breaks the pages for some disabled users, rendering content structure less understandable.

HTML5 is definitely a step in the right direction. It's great not just for accessibility but for developers too. Unfortunately, relying on browsers is still an issue. Looking at you, Microsoft!

The important thing is to not get dissuaded from using these HTML5 elements because of browser support. They're great in so many ways. Sometimes there are better choices, and you may need a little extra work to make a feature useful. Some of the 40 new HTML5 elements aren't implemented by any browser, or only by browsers that don't yet support assistive technology. As a consequence, it may not yet be practical to use a particular HTML5 feature.

Developers need to remember that the web is for everyone, and keeping the importance of accessibility in mind is the surest way to build for that. Navigating a site should never be a chore. If a visually impaired person can't find something others can, that's a future visitor lost. No one wants to lose visitors.