Web accessibility can be defined as an inclusive practice that removes barriers that prevent interaction with, or access to websites, by people with disabilities. Web accessibility is often overlooked by many developers. But the fact is that web accessibility not only benefits the disabled but also every user. In this article, we will show you how to build a website with accessible content for older users, people with disabilities and those with accessibility needs.

What is web accessibility and why it is important?

Tim Berners-Lee, the inventor of the World Wide Web, described web accessibility in these terms:

“The power of the Web is in its universality. Access by everyone regardless of disability is an

essential aspect.”

In essence, web accessibility is the provision of online information for people with disabilities.

The flexibility of the internet means that people with disabilities can use a variety of hardware and software accessibility tools, often called Assistive Technology (AT) products, to access websites. AT and associated accessibility features are often built into the operating system of computers such as Windows and Mac, and mobile devices such as the iPad and Android-based devices. Additional AT can also be installed depending on the needs of the individual.

Some examples of accessibility features include:

• Screen reader:

  It is an application that can read out the text and speak it. This will be helpful to people who are visually impaired.

• Screen magnifier:

  This zooms or enlarges the content.

• Themes:

  High contrast themes allow people with vision impairments to change the colors for their comfort and increase the size of mouse pointers and text.

• On-screen keyboard:

  Specifically, on-screen keyboard helps the mobility impaired persons by enabling them to type using a pointing device.

• On-screen alerts:

  For people with hearing impairment, Messages should be shown in the place of sounds.

Guidelines to build an accessible website:

W3C WAI developed WCAG 2.0, designed to be technology-neutral so that it would continue to support the creation of an accessible web regardless of technical developments. WCAG 2.0 was

released in 2008 and consists of four design principles – Perceivable, Operable, Understandable and Robust (POUR) – which in turn consist of 12 guidelines

Perceivable

1. Text-alternatives should be provided for non-text content.
2. Provide captions and other alternatives for multimedia.
3. Content that can be presented in many ways should be created, Including by assistive technologies, without losing meaning.
4. Seeing and hearing content should be made easy.

Operable

5. All the functionalities should be made available from the keyboard.
6. Users should be given adequate time for reading and understanding the content.
7. Content that can cause seizures should not be used.
8. The users should be helped in navigating and also finding the content.

Understandable

9. The text should be easy to read and understand.
10. The content should appear in a predictable manner.
11. Lastly, the user should be helped to avoid the mistakes.

Robust

12. Increase the compatibility with latest tools.

Most Common Web Accessibility Mistakes & their solutions:

1. Every element should consist of text or an image with ALT.

Text should be added to the kink and if it contains an image ALt text should be added. Because without text screen readers may only read URL.

2. Headings should not contain other headings.

The nested headings should be removed and replaced with SPAN elements.

3. IMG ALT text must not be the same as the image file name.

Change the ALT text to a description of the image.

4. IMG elements must have an ALT attribute.

Add an ALT attribute describing each image, which screen readers read aloud. Spacer images and purely decorative images should use ALT

5. Inserting spaces between letters in a word means screen readers cannot pronounce the words correctly.

Remove spaces between letters in the same word (e.g. “hello” instead of “h e l l o”).

6. LABEL elements should not be blank.

Add text to the LABEL describing the associated control.

7. No TITLE attributes found for the frames on these pages.

Add a TITLE attribute to each FRAME and IFRAME element (e.g. TITLE=”Main Content”). Without a TITLE some screen readers read out the FRAME filename, which is usually meaningless.

8. Some pages have the same title, so the title cannot be used to distinguish pages.

Change the TITLE elements so they are unique for each page.

9. Duplicate IDs in the page causes the problem to screen readers.

The ID should be unique. Duplicate IDs not only causes problem to screen readers but also to the JS methods and makes them behave inconsistently.

10. Any opened tag that is not closed properly will cause the screen reader to miss the content.

All the opened tags should be closed properly without missing even a single tag.

Guideline: WCAG 2.0 A F70

11. Using ALT text which duplicates link text in the same link or the following link results in screen readers stuttering as the same text is read out twice.

Use ALT= ” when the image is part of a link containing text, or change the redundant ALT text if the links are separate.

Guideline: WCAG 2.0 A H2

12. Ensure that foreground and background colors have enough contrast.

Some users find it hard to read light gray text on a white background, dark gray text on a black background and white text on a red background.

• The contrast ratio should be 3.0 or more for 18 point text, or larger
• And the contrast ratio should be 3.0 or more for 14 point bold text, or larger
• The contrast ratio should be 4.5 or more for all other text

The foreground/background contrast ratio is 4.2 with 12 point text.

Guideline: WCAG 2.0 AA 1.4.3

13. Headings should not be empty.

Add text to the heading, or ALT text if the heading contains an image. Screen readers read out page headings, allowing users to quickly skip to a section, but some older screen readers do not ignore empty headings.

Guideline: WCAG 2.0 AA G130

14. Phrases in a different language should be in a SPAN or DIV with a LANG attribute.

Non-English phrases in English text will be mispronounced by a screen reader unless they are identified with a LANG attribute.

Guideline: WCAG 2.0 AA 3.1.2

15. 
    

    Form field labels should be unique on a page or enclosed in a FIELDSET with a LEGEND that makes the label unique.

When a form contains items with the same label, screen reader users find it difficult to tell them apart. Adding a fieldset with a legend differentiates the controls, because the legend text is announced along with the label text. For example: <legend> Gift wrapped: </legend> <label> Yes </label> <label> No </label> <legend> Express delivery: </legend> <label> Yes </label> <label> No </label>

16. All ONMOUSEOVER/ONMOUSEOUT handlers should have an equivalent ONFOCUS / ONBLUR handler.

Some users are unable to use a mouse, so use the keyboard instead. Add an equivalent keyboard event handler to help these users.

17. Identify row and column headers in data tables using TH elements, and mark layout tables with role=’presentation’.

Data tables allow screen reader users to understand column and row relationships. Layout tables read cells as a series of unrelated paragraphs with no tabular structure. Without TH or ROLE, screen readers apply heuristics to decide whether a table is a layout table or data table. These heuristics vary greatly between screen readers and are affected by browser being used, window size, and font size (so the outcome is very unpredictable without TH or ROLE). If a data table has headers marked up using TD, then change these to TH. And if a data table has no headers, add TH elements describing each row and/or column. In case, the table is only used for layout add role=’presentation’ to the TABLE element.

18. For data tables that have two or more logical levels of row or column headers, use markup to associate data cells and header cells.

Include ID attributes in TH cells and HEADERS attributes in the associated TD cells, or include SCOPE attributes in TH cells.

19. When pages utilize scripting languages to display content, or to create interface elements, the information provided by the script shall be identified with functional text that can be read by assistive technology.

Content and functionality provided by scripting is directly accessible to assistive technologies and the keyboard. <noscript> content does not constitute a suitable alternative to inaccessible scripting.

20. 
    

    The design of a web page should be in a way that the information on the web page which is presented in color should also be available without color.

Color is not used solely to convey important information. Sufficient contrast is provided.

As discussed already, when designing applications Web accessibility should also be given high priority. This can also improve the user base to great extent and increases the usability of the application. So it is mandatory that all the developers should design and also perform the accessibility tests for applications. In that case, for more on web development follow Agira technologies.