Website Accessibility 101

The internet provides a wealth of opportunities, but not all users can enjoy the advanced technologies that make modern websites diverse and dynamic. To most people, the features we are used to are normal and easy to use, be it pop-up windows, playing video content, or simply using a mouse. But there is an aspect of website creation that developers should keep in mind: website accessibility. What is it about?

Who needs websites to be accessible

The very name of the aspect implies it is about those who are restricted in their capabilities. Among these are the disabled, people with dyslexia, colorblindness, etc., i.e. those users who cannot use at least some part of the content or interface due to having impaired vision, hearing or other ability.

People who have no such health problems usually take their ability to use websites to their full potential for granted, but in case of people for whom it is impossible, assistive devices should be used and special measures taken by web developers.

Web Content Accessibility Guidelines (WCAG) and WCAG 2.0

OK, so what makes an ultimately accessible website? Can I just think of a couple of problems users might experience, find a solution to them myself, and call my project accessible?

No. Web accessibility is regulated and standardized. There are organizations issuing recommendations regarding what steps should be taken to ensure access of all categories of users to web content. This is not to say that you will be punished if you fail to meet the requirements (these are set only for governmental and other global websites), but complying with the rules of web accessibility is recommended to any developer. By following them, you can make sure no visitor is left behind.

The World Wide Web Consortium, which is often abbreviated as W3C, issued guidelines which are now considered standard and recognized worldwide (although even they do not address all the problems users with disabilities have to face).

There are two sets of guidelines by W3C. The first one dates back to 1999, when the first step was taken to make the burgeoning online industry available to the disabled. The recommendations, abbreviated as WCAG, comprised 14 guidelines of three priority levels. Priority one meant basic accessibility, which is the lowest level of accessibility you can have – although it is still better than none. Priority two was used for accessibility solutions that help users overcome the most significant problems experienced when using websites, so it focused on eliminating major barriers. And finally, priority three was about good accessibility levels and addressing the majority of problems users with impairments may have.

An updated version of the guidelines was rolled out in 2008. Unlike the previous WCAG, WCAG 2.0 focuses on principles instead of technology, which makes it applicable to many websites regardless of what technology they use. As new technologies were emerging, it was becoming more evident that guidelines should provide possible solutions for problems without offering particular technologies as the only way to improve accessibility.

WCAG 2.0 principles are easily to remember with the help of mnemonics: POUR (perceivable, operable, understandable, and robust). What does it mean?

• Perceivable. This criterion revolves around senses. Not all users can employ vision, hearing and touch to use the internet, and it is up to the developer to make sure website content is easy to use and can physically be perceived by a person with disabilities.
• Operable. This one is aimed at ensuring all users can navigate your page and use its features. Many of those with impaired vision and motor disabilities have to resort to the keyboard-only mode and avoid using a mouse. A developer should take it into account and make all elements of a website accessible even if there is only a keyboard available. The same is true of forms: filling them in can be a challenge, and assisting users is a must. Another important recommendation is not to set time limits, as it may take them quite a long time to do a thing that is considered easy by healthy people.
• Understandable. The previous two criteria address physical use of websites (i.e. how content can be perceived and used with regard to physical abilities). The “understandability” criterion is about making a website easy to use intuitively in terms of features and content. Let all the content be clear, and all the features should be user-friendly: if there is unclear navigation or a function that is difficult to use (say, when a user has to spend a lot of time learning how to use it or to look through other pages to find out how a particular action is performed on a website), website visitors will have to open new tabs, search elsewhere or do other things that are time-consuming and difficult for them. In some cases, they may fail to use your website at all if it is not understandable enough.
• Robust. While somewhat vague, this criterion means that your website should support a wide range of assistive devices (such as screen readers) and third-party software used by people with disabilities. The standards are listed on the WCAG 2.0 page, but the most important ones are error-free CSS and HTML.

The three priority levels (1, 2 and 3) that had been used in the previous version were converted to levels A, AA and AAA with almost the same definitions. While it may seem reasonable to implement all the things listed under the AAA category, many websites, including those run by the government, use a combination of AA and AAA solutions. This approach enables them to address the majority of the most widely spread issues.

NOTE. If you cannot use all the AAA recommendations listed in the guidelines (because not all these features can be implemented on any website), it does not mean you should neglect the accessibility aspect. Try to introduce as many improvements as you can – even if your page cannot be fully AAA-compliant.

Websites’ structure 

In order to address problems experienced by the majority of users with disabilities, you should focus on three aspects of a website: its structure, the visual part, and the audio part. There is much more to web accessibility than that, but these three elements are what makes the basis of accessibility.

Making your website accessible in terms of structure is a complex endeavor, as it embraces several measures. Good structuring lays the foundation of efficient navigation, which benefits user experience. Actually, it is what should be kept in mind by any developer, as all users, regardless of their health problems, can benefit from content being well-structured.

• Headings. Making use of headings can help you label page sections and make navigation easier – especially if assistive devices are used. A heading is not anything in bold and looking like a heading. Headings can vary in importance, and this difference is expressed through the use of different heading ranks, ranging from <h1> to <h6> (from the most important to the least important ones). Headings can help you organize passages of text and avoid confusion when a website user with disabilities tries to make heads or tails of what is where on your website.
• Page regions. By employing HTML5 and other means of page organization, like WAI ARIA to define page regions, you can make page structure easily understandable. These include <header>, <footer>, <nav>, <main>, etc.
• Region labeling. Aria-labelled by and aria-label can help you render all sections of website accessible by making them easier to distinguish. Note that unique regions are not labeled.
• Content structure. <section>, <article> and other elements can help introduce more semantics into your content, thus making it easier to use by assistive technologies which rely on such information.

Remember: marking up your content and clear structuring make a website more accessible due to clear organization of content and providing more information for assistive devices, which, in their turn, can bring your information to users by converting it into something they can perceive easily. The better the structure, the more content you can make available to them.

Visual part

Visually impaired users include not only those who are blind, but also those who are colorblind, have a degree of visual impairment (which may vary), etc. To make a website accessible to people with impaired vision, you can do the following.

• Do not forget about the enlarged text option. Not all users can see the default font size. Alternative stylesheets is a good option, but you should make sure the layout remains the same even if the font size is made larger. Many users prefer to have an option of adjusting text size without other elements changing their size – that is why it is not enough to zoom using browser features, as in this case the entire page with all its elements and sections is scaled. If your website’s target audience is those who are more likely to be visually impaired, say, the elderly, you can make the font larger by default. If it is large pieces of text that make up a significant share of your website content, consider offering separate text-only versions of pages so that users can have an opportunity to adjust it the way they want.
• Mind the contrast. Users with contrast sensitivity, including those with glaucoma, cataracts, retinopathy, etc., have difficulty differentiating between subtle shades and brightness levels. Since many layouts employ a wide range of details with exquisite design, it can be difficult for users with impaired vision to use content the understanding of which depends on color perception. Again, an alternative stylesheet can be a good option. Consider adding more contrast in it, make texts bold, and try not to use fonts that are thin (like those imitating handwriting). Another recommended step is to avoid CSS or JavaScript code that prevents users from highlighting elements and text: many users with impaired vision use this approach to increase contrast fast and easy.
• Choose colors wisely. Colorblindness affects quite a lot of people (around 8% of men, and 0.5% of women). These figures become even more impressive if we count those who suffer from acquired, not genetic, colorblindness. Make sure action items (which are supposed to employ color to define the function of a button) do not use easily confused colors (like red and green for ‘No’ and ‘Yes’).
• Make mobile versions available to desktop users. Do not restrict use of your website mobile version (if you have one), as mobile-friendly websites are usually simplified, less cluttered, and easily scaled.
• Introduce keyboard shortcuts. Keyboard shortcuts can be of great help not only to those using screen readers, but to all users with impaired vision. Better and faster navigation is achieved by using keyboard commands instead of following a mouse cursor – something considered difficult by many visually impaired website visitors.

Audio part

Users with impaired hearing also have special needs. If podcasts and videos are the primary source of information used on your website, you should provide users with alternative ways of getting this information.

For podcasts, there should be text transcripts, and all videos should have subtitles. Another thing to use is video descriptions – these can be accompanied by audio versions of descriptions to be read aloud by screen readers.

Make sure the auto-play feature is not on by default. Users with impaired hearing or vision or motor disabilities usually cannot stop it quickly. You can use auto-play as an option, but it should not be turned on the first time a user sees a page.

Try using a more accessible media player, like the ones based on HTML5 (YouTube is one of them). The reason for it is that they enable use of controls and are characterized by better navigation.

WAI-ARIA recommendations

The abbreviation stands for a suite of web standards called the Accessible Rich Internet Applications. It aims at defining ways for improved functionality, especially if it is based on advanced technologies, like JavaScript, Ajax, etc. Everything used to make content dynamic also falls into this category.

Features like drag-and-drop, tree controls, and dynamic content that changes after an action is performed or if time-based updates are used, are often unavailable to users with disabilities – either because they cannot use a mouse or due to other reasons. Such features, although advanced and useful, are difficult for screen readers to interact with and extract information from.

The WAI-ARIA recommendations aim to solve these problems and convert the information provided by dynamic content and advanced technologies into something that can be processed by screen readers and thus used by all users regardless of whether they are disabled or not. More detailed information about the suite can be found on the W3C website.

Dynamic content specifics

Making dynamic content accessible is closely connected with compliance with the recommendations issued by W3C (see above). The problem with dynamic content is that when content is updated without a page refresh, many assistive devices fail to notice it, and the newly published information is not available to users. Page overlays can also become a problem for those who use only keyboards.

To improve accessibility of websites filled with dynamic content, you can use ARIA alerts and roles. Widgets should be tested beforehand to make sure they are accessible. Remember that video auto-play is not an option (it is considered part of dynamic content too). Special front-end development frameworks can be utilized to tailor your page to the needs of those who cannot use standard page versions.

Web accessibility and the law

Today, web accessibility is part of legislation is many countries. The reason for it is that it ensures equal opportunities for all people to use online resources. In other words, web accessibility is part of equality laws.

The list of countries where websites must comply with accessibility requirements includes Canada, the U.S., the UK, the EU, India, Hong Kong, Australia, and New Zealand.

In the U.S., web accessibility is governed by the Americans with Disabilities Act. The focus is primarily on government and public-sector websites, which must be accessible by law. The same is true of the European Union. In the UK, more attention is paid to treating all users equally: if a service provider treats a person less favorably because of his or her being disabled, it is considered discrimination. For instance, if a person with dyslexia cannot purchase goods or apply for a job due to the website of this company being inaccessible, it is a discrimination case.

How to comply with the standards

The recommendations listed above may all come in handy when making your website as accessible as possible. Here are more tips, which are more condition-specific, on how to improve user experience.

Dyslexia

For people with dyslexia, fonts matter. Dyslexia-friendly interfaces are easier to read. Times New Roman and other standard fonts may not be the best option, as research suggests.

There are special fonts that can be integrated in the main version of your website or be part of a special version for dyslexic users. One of these is OpenDyslexia, which is a free font face characterized by weighted bottoms: this design helps users see the line of text clearly and avoid at least some of the reading mistakes they make.

There are other options, like Dyslexie. The findings of studies focusing on the effectiveness of specialized fonts suggest that they do not help reduce reading times, but they may help improve accuracy.

Font color is also of importance. There is scientific evidence suggesting that dyslexic people read quicker if lower color contrasts are used.

You can check whether your website complies with the requirements set for websites accessible to users with dyslexia here: http://webaim.org/simulations/dyslexia 

Colorblindness

Colorblindness prevents people from perceiving content the way it was designed to be perceived. Some types of colorblindness are more prevalent than others (like red-green colorblindness, for instance).

The key message here is not to rely on color to convey crucial information. Say, if there is a metro map, distinguishing routes is impossible if the only way to tell one from another is to see what color it is.

You can check whether your website complies with the requirements set for websites accessible to users with colorblindness here: http://webaim.org/resources/contrastchecker/

Section 508

Another thing to mention is Section 508. Section 508 is a section added to the Workforce Rehabilitation Act. According to the amendment, federal agencies must develop and use technologies, both information and electronic, that are accessible to everyone regardless of whether they are disabled or not.

This applies to a lot more types of devices, so it is not limited to websites. Among such devices and means of communication are tablets, telephones, software, websites, DVD players, TV, laptops, webinars, printers, support provided by call centers, laboratory equipment, etc.

Section 508 is for federal government agencies and all states that receive money due to being included in the Assistive Technology Act State Grant program.

You can also check whether your website complies with the section 508 requirements here: https://webaim.org/standards/508/checklist

Web Compliant Doesn’t Mean Ugly

As seen from what is written above, making your website accessible is not easy. It requires technical knowledge, the skills to design your pages in a way that makes it easy to navigate, and the efforts to learn more about what you can do to improve user experience.

Web accessibility means restrictions, in terms of either design or features used. That said, it does not mean web compliant websites are ugly. Provided you are a skilled designer (or know one who can help you), you can make a neat page that is not devoid of its distinctive style. Alternatively, you can use different stylesheets to tailor your page to the needs of many visitors that may come across your website.