What is Web Accessibility?

Accessibility “means that websites, tools, and  technologies are designed and developed so that people with disabilities can use them. More specifically, people can: perceive, understand, navigate, interact with the Web and contribute to the Web.” Web access is an umbrella term in which are encompassed all the disabilities that can affect the navigation on Web auditory, cognitive-motor, neurological, speech and visual.

Web accessibility means that people with disabilities can use the Web.

Why Is Web Accessibility Testing Necessary?

Accessibility testing is necessary and important for the people, business and society – The ENTIRE community.

As the influence of digital media is increasing day by day, websites and digital applications have become an inevitable part of education, healthcare, entertainment, banking, insurance and many more. It is essential that these be made accessible for people with diverse abilities.

Accessibility is also required by law in many cases and many countries have made it mandatory.

The different types of impairment are mentioned below:

  • Visual: Complete blindness or color blindness or poor eyesight, visual problems like refractive errors and blurry visions.
  • Physical: Difficulty using a keyboard or mouse.
  • Cognitive: Learning difficulties or poor memory.
  • Literacy: Reading problems, finding words difficult.
  • Hearing: Auditory problems like deafness and hearing impairments, difficulty hearing well or hearing clearly.

The WCAG 2.0 is organized in three different levels:

  • Level A: the most basic Web accessibility features;
  • Level AA: the most common barriers for disabled people;
  • Level AAA: the highest level of accessibility.
Even level A is just the beginning, and the level AA embraced on large companies’ websites, the level AAA is the one to which is hoping that someday all the Web products will go. For reaching those, it’s very important to have empathy for your users, they need to have excellent experiences on the Web, too.

How to Make Web Accessible

Making the web accessible depends on the developers building for the web. Making your website accessible to people with disabilities, will end up making it accessible to everyone.

Accessibility Testing Best Practices – Technical Standards

Use Default HTML Tags

Please for web accessibility, don’t mess with the default html tags. Use buttons for buttons not anchors for buttons. To make anchors work the same way as buttons you need to add additional JavaScript event which is a very dumb approach when you could easily use the normal naked button. Use buttons for buttons, anchors for links, “table, tbody, td, th” for tables, “h1, h2, h3, …h6” for titles and so on.

<h1>My First heading</h1>
<h6>My last heading</h6>

Without heading tag

<div role=”heading” aria-level=”1″>Heading details</div>

The use of Alt-tags

The alt-tag or alternative (alt) html attribute is basically used to describe an image.

  • Purely decorative images should have ALT=””.
  • All meaningful images should have descriptive alt text.
  • All navigation image buttons should have descriptive alt text.

In HTML, it looks the same thing like this:

< img class=”brand” src=”image-location” alt=”this is where your image description goes” />

Focus Indicators

As you tab through the elements on the page, can you see where you are? Keyboard-only users need to see where they are on the page to effectively navigate the page.

.title:focus {
outline: 1px solid #45A5E5;
box-shadow: 0 0 5px rgba(51, 170, 238, 0.5);
}

Use the ARIA Tag

The role attribute defines a specific role for type of object (such as an article, alert, slider or a button). Additional ARIA attributes provide other useful properties, such as a description for a form or the current width of a progressbar. ARIA attributes can also be used to specify active or disabled state for objects(especially buttons).

You can checkout this site to know how to use ARIA

<button aria-label=”close” role=”button” tabindex=”0″ class=”modal_button” (click)=”close()”></button>

Keyboard focus on forms

  • Tab order of forms should be logical.
  • If there is a drop down menu, users should be able to navigate and select items using keyboard alone.
  • Data entered should be retained if the page is refreshed or too much time is taken to fill out the form fields.
  • If a required field is left blank, keyboard focus should shift to that field when the user is notified.
  • As soon as you submit the form and an error appears on the field, keyboard focus should be set on that field.

< input type=”text” id=”titleInput”  autocomplete=”honorific-prefix”  tabindex=”0″  type=”text”  formControlName=”title”  (blur)=”trim(‘title’)”  aria-label=”title”>

Select option
< select aria-label="AM/PM"  [formControl]="formState.startAmm" (change)="timeChange()"  [attr.disabled]="(formEvent.value === true ||  !canEdit) ?  ' '  :  null " >
< option value="AM"> AM < /option>
< option value="PM"> PM < /option>
< /select>

Dialog box and pop-ups:

  • As soon as the dialog opens up, keyboard focus should be set on the dialog.
  • Dialog can be dismissed using keyboard.
  • When the dialog is closed, focus should be set on the element which activated the dialog on the parent page.

< div class=”modal”   id=”add_modal”    tabindex=”-1″    role=”dialog”    aria-labelledby=”defModalHead”  aria-hidden=”true”   FocusTrap=”true”>

Testing using a screen reader

Screen readers are the tools used for narrating the content of a page. A screen reader can narrate everything for the user like the texts on the website, links, checkboxes, radio buttons, images, etc.
Below are the commonly used screen reader combinations with browsers:

Links and alert message:

Ensure ‘Links’ are descriptive without generic text such as “Click Here”.

Ensure that the role assigned to the “Link” on the site is announced by the screen reader.

Alert success message

< div class="alert alert-success"  role="alert" >
User profile updated successfully.
  < /div>

Forms:

  • Form fields should have descriptive labels.
  • Appropriate descriptive labels should be present and read by the screen reader.
  • Users should be able to fill out the form and submit it successfully.
  • Buttons should be labeled and read correctly by the screen reader.
  • Required/optional fields should be announced by the screen reader.
  • Errors on the form field should be announced by the screen reader as soon as they appear.

Color Contrast Analyser:

Color Contrast Analyser (CCA) helps to keep sufficient contrast between foreground and background colors by providing appropriate test results.

Fail state:
Foreground:  #9B9B9B
Background:  #F8FAFC
The contrast ratio is:  2.7:1

Pass state

  • Foreground:   #337ab7
  • Background:   #ffffff
  • The contrast ratio is:   4.5.1

You can checkout this site to know how to use color contrast.

Axe Browser Plugin:

Axe is a browser plugin for Chrome and Firefox web browsers. It scans the web page to find for WCAG 2 (Web Content Accessibility Guidelines 2) and Section 508 (Standards defined for Federal Agencies) accessibility and reports the violations. The axe-Chrome extension utilizes the axe open-source JavaScript library developed by Deque Systems.

Conclusion : –

Always have web accessibility at the back of your mind when building a website. That is ensure you are building for everyone that have access to the web.

References :

Keyboard shortcuts for screen-readers:

NVDA:
https://webaim.org/resources/shortcuts/nvda

JAWS:
https://webaim.org/resources/shortcuts/jaws