Developing for Web Accessibility

by

HTML 5 represented in American Sign Language

When developing websites it is important to consider your audience and how they interact with your application. This can be even more significant for a person with disabilities. Even the most stunning visual presentation can lose its value when the content cannot be interpreted by an individual due to, for example, a learning disability or difficulty seeing. Therefore, it is important, when doing any development or design, we do not dismiss the 1 in 5 people that would benefit on an accessible web.

“It is a complex phenomenon, reflecting the interaction between features of a person’s body and features of the society in which he or she lives.”

World Health Organization

Persons With Disabilities

According to the US Census Bureau approximately 19% of Americans have a disability. A person can have different disabilities; some, including examples, are as follows:

  1. Auditory
    • Hard of hearing
    • Deafness
    • Deaf-blindness
  2. Visual
    • Low vision
    • Color blindness
    • Partial blindness
    • Blindness
  3. Cognitive
    • ADHD
    • ASD
    • Memory impairment
    • Seizures
  4. Physical
    • Amputation
    • Arthritis
    • Dexterity issues
  5. Speech
    • Speech sound disorder
    • Stuttering
    • Muteness

Looking at a partial list of disabilities it is easy to see that there are many different ways that these disabilities may impact a person’s use of the internet. More information on different disabilities a person may have or the different ways a person may interact with the internet can be found on the Web Accessibility Initiative page on the W3C site.

How to Include Others

There are a few key things we can do to help include others.

Understanding Disabilities

Begin to understand how a disability may cause awareness to certain unwanted behaviors in a page:

  • A blinking page – could cause distraction or trigger seizures
  • Content with disrupted flow – could make the page un-engaging
  • Required audio with no captions – could mean the content goes unnoticed or missed

There are so many scenarios that could easily be mitigated by simply understanding.

Learning the Tools

Various tools are also used by people. A simple one that may be overlooked is a keyboard. Any website should be accessible simply by keyboard input. When this is taken into consideration and the website is fully accessible through the keyboard we include those that may have decreased dexterity or even visual disability.

Screen readers are another tool that many use. Two common ones are JAWS and VoiceOver. Screen readers do not only read out what is on the screen; they also describe the experience of the website. When a screen reader comes across an image it can read off the alt text for an image describing what’s there.

Use Evaluation Tools

There are many different tools that are available for evaluating your website. For the Chrome browser you can find NoCoffee and Accessibility Development Tool in the extensions library.

NoCoffee is a tool that provides you with different visibility traits. It allows you to view a page with a variations of color blindness, partial blindness, low vision, etc. It is a good tool when manually trying to assess if the website is usable to someone with a visual disability.

The Accessibility Developer Tool is a simple auditing tool that will go through and compare your website to various known accessibility issues. This is helpful to determine whether or not your page may have some text that is not easy to read. It may also help you quickly identify images that are missing an alt text.

Best Practices and Guidelines

There are many best practices or guidelines available on the internet. The most complete is the WCAG 2.0. The a11yproject checklist also provides developers with a simple checklist to review when assessing whether or not a website meets some of the basic accessibility goals. A final guideline, Section 508,  is one specific to U.S. government websites. Any government website must meet these standards. Originally published in 2000 it has undergone some updates and is not as complete as WCAG 2.0.

Leave a Reply

Your email address will not be published. Required fields are marked