Web Accessibility: The Art of Being Inclusive

The Importance of Providing a Consistent Experience for Every Customer

Introduction

Accessibility is the practice of removing all barriers from your web site or application so that all users can access, perceive, understand, navigate, interact, and contribute equally.

Most modern applications already remove some barriers for users, although it is not often thought of in those terms. For example, sites that are designed to work on any device, window or screen size are built to be inclusive. It would be an access barrier if sites required a specific device or specific screen dimensions to use the site. However, modern standards make it possible for two users accessing the same web site, one from a phone and one from a widescreen desktop monitor to view the site in a consistent and reliable way.

But what about users who can’t view a web site?

For users with disabilities, viewing a site, interacting with a mouse, listening to an audio clip, or clicking a button may be difficult or even impossible. An accessible site should be designed to provide inclusion so that two users with very different disabilities can still comprehend and interact with the site in a consistent and reliable way.

What Is Disability?

According to the Centers for Disease Control and Prevention, “A disability is any condition of the body or mind (impairment) that makes it more difficult for the person with the condition to do certain activities (activity limitation) and interact with the world around them (participation restrictions)."

In the web industry, accessibility is often misinterpreted as designing to support permanent physical disability, such as blind users. However, accessibility should be implemented with the goal of providing complete and equal access to anyone experiencing permanent, temporary, or situational disability. When overall inclusion is the goal, users in all three categories of disability benefit.

  • Permanent Disability
    • A persistent, usually physical, disability where no change in limitation is expected.
  • Temporary Disability
    • Usually the result of an injury, surgery, or illness that is expected to result in eventual recovery.
  • Situational (or momentary) Disability
    • Impairment brought on by a person’s surroundings or current environment that is not directly caused by a temporary or permanent disability.

Regardless of the type of limitation, a disability becomes a challenge to a user when it impedes the normal, intended use of a site, and may include:

  • Vision
    • permanent: total or partial blindness, color blindness, low vision
    • temporary: cataract, vision impairment after surgery, dilated pupils
    • situational: screen glare, interacting with site while driving
  • Hearing
    • permanent: deafness, permanent hearing impairment
    • temporary: ear infection, impairment induced by loud sound
    • situational: loud environment, broken speakers or headphones, in a quiet place where volume must be kept low
  • Motor
    • permanent: paralyzation, missing digits or limbs, tremors, loss of muscle control
    • temporary: wearing a cast, broken digits or limbs, recent arm or hand surgery
    • situational: holding a baby, holding a phone, broken mouse, dirty hands
  • Cognitive
    • permanent: autism, dyslexia, intellectual or memory loss, difficulty understanding or making choices
    • temporary: alcohol or substance intoxication, sleep deprivation
    • situational: environmental distraction

Why Develop for Accessibility?

Keyboard Brail

When creating a web application, ensuring it is accessible to all members of your audience is certainly a value to the user. Good accessibility practices may even set you apart from your competition. However, accessibility is not just good customer service and should not be viewed as a “nice to have”.

United States federal government agencies and contractors are required by law under the American Disabilities Act (ADA) to be fully compliant with all Web Content Accessibility Guidelines (WCAG) 2.0. This requirement was originally added to the ADA in 1998 as Section 508 and is often referred to as “508 compliance”.



Web Content Accessibility Guidelines

The Web Content Accessibility Guidelines (WCAG) is a set of guiding principles and technical standards developed by the W3C Web Accessibility Initiative (WAI).

These guidelines provide best practice information that assist anyone producing content and web sites to be as accessible and inclusive as possible. Their technical documentation provides a road map that aims to give all combinations of disability the most likely path to have obstacles to utilization removed.

For more information, visit https://www.w3.org/WAI/standards-guidelines/wcag/.

The Private Sector Obligation

Private sector businesses also have an obligation to provide accessible web applications because the ADA prohibits discrimination based on disability in public places. The United States Department of Justice has confirmed that web sites fall under the category of public space and must honor the ADA.

Unlike government institutions, private businesses do not have a specific requirement of accessibility level or technical guidelines under the ADA, but United State courts have used WCAG as an acceptable measure of accessibility compliance. Therefore, the techniques and practices outlined by WCAG 2.0 and 2.1 should be the goal for all businesses, especially because failure to do so could potentially result in litigation.

Developing Sites for Accessibility and Inclusion

Assistive Technology

To overcome the disability challenges when using the web, users typically rely on technologies that provide alternative means of accessing, perceiving, understanding, navigating or interacting. These technologies allow users to interact with the web using methods that best suit them and therefore make utilization as easy as possible for their specific circumstances.

Typically, as developers, when we talk about building accessible applications, what we’re really saying is that the application is designed so that both traditional and assistive technologies will be able to fully interact with and translate and deliver the content.

Assistive technologies include:

  • Screen readers
  • Screen magnifiers
  • High contrast/color modification software
  • Voice recognition software
  • Refreshable braille display
  • Alternative input devices (alternative keyboard, alternative mouse, mouth stick, head wand)

Two Methods to Achieve Accessibility

There are two approaches that work together to achieve accessibility for users and the devices they use.

The first is through markup itself; through the native HTML that the browser is rendering. That is, ensuring that the HTML provided is giving clear, structured, and semantic information to the browser.

The second method uses Accessible Rich Internet Applications (ARIA) which is designed to provide additional meta data and information about what is happening on screen. ARIA works as an extension of the HTML to provide information that HTML alone does not provide.

Because accessibility is a broad and deep topic, and the specifics are too detailed to cover in one article, we’ll focus here on the first part of these methods. When important to the HTML structure, we’ll call out ARIA, but otherwise, will not dive deeply into the topic. More on ARIA later.

An Accessibility Checklist

Checklist

Even following a checklist, that is no guarantee of complete accessibility because every application and circumstance is unique.

As stated by the W3C, “Note that even content that conforms at the highest level [of accessibility] (AAA) will not be accessible to individuals with all types, degrees, or combinations of disability, particularly in the cognitive language and learning areas.” They further state, “Web technologies can be used in ways that are not accessibility supported as long as they are not relied upon and the page as a whole meets the conformance requirements…” However, following these guidelines will help eliminated common accessibility barriers, and help ensure that browsers and assistive technologies work with an application as intended.

General

  • Is markup valid? Validate HTML markup. Correct any improper nesting, unclosed elements, stray tags, block level elements inside of inline elements, duplicate IDs or any other validation issues.
  • Is language defined? Declare the correct written language of a page in a lang attribute on the HTML element.
  • Are all pages uniquely titled? Provide a unique and descriptive title that matches the content of the page.
  • Are landmarks used? Utilize HTML landmarks to contain important areas of a page. As examples, these common HTML elements should be used to contain important areas of each page:
    • Header – page header that does not include navigation
    • Nav – navigation
    • Main – main content of the page
    • Section – a defined region of a page such as a callout block inside of the main content
    • Aside – secondary content that is complementary to the main content
    • Form – a block of inputs
    • Footer – page footer
  • Are correct semantic elements used? Pages should be constructed to use the most semantically correct HTML elements for all content. As examples:
    • ul or ol to contain lists
    • p for paragraphs
    • table for tabular data, including correct and appropriate us of a th headers, scope attributes and caption, as appropriate
    • strong for strong emphasis
    • em for emphasis
    • blockquote for quotes
    • code for blocks of programmatic code
    • sub for subscript
    • sup for superscript
  • Are anchor elements used correctly? An anchor should only be used to link to a location on the page, another page or another site and must contain a href attribute with valid destination. Anchors should not have href destinations or normal behavior suppressed or changed. If it is necessary for an anchor to not behave as a link to a destination and is instead performing a function, a button element is likely more appropriate.
  • Is deprecated markup avoided? Avoid deprecated HTML elements and attributes like center, menu, align, height, width, language, nowrap, border, bgcolor, or background. When an element like height is needed, opt for a CSS equivalent.
  • Can the viewport be zoomed to at least 200%? Avoid disabling a browser’s ability to zoom the viewport and support a 200% zoom level at minimum.
  • Can a timeout be extended? Provide users with the mean to extend or cancel a timeout event. For example, if an application automatically logs a user out of a session after a specific people of time, a dialog should be presented asking the user If the application is still in use with the ability to cancel the timeout.

Content

  • Does the page contain a single, unique h1 tag? Each page should contain a single, primary heading, h1 element. Like unique page titles, every h1 should be unique within the application and adequately convey the high-level purpose or name of the page.
  • Are text headers used in logical order? Author pages so that heading elements like h1, h2, h3, h4, h5 and h6 follow natural reading order. For example, an h3 should only ever appear as a logical child of a section labeled by an h2 and never appear before an h2.
  • Are title attribute tooltips avoided? Remove or avoid the title attribute entirely. It is inconsistently supported by browsers and can interfere with assistive technologies. When a tooltip is required, use an alternative, accessible method.
  • Are buttons and anchors descriptive? The written content of a button or link should describe its destination or purpose. For example, avoid buttons that use text like, “submit” in favor of more descriptive actions like, “submit application”. Avoid links that contain text like, “click here” or “read more” in favor of descriptive text. Use anchor text like the name of an article or a descriptive action like “download a free eBbook”.
  • Is content written at an 8th grade level? Unless there is a compelling or academic reason, content should be written at an 8th grade reading level and avoid needless figures of speech or metaphors.

Color

  • Is color contrast sufficient? Color contrast of onscreen text and icons should comply with minimum contrast ratio requirements. Contrast can be checked at https://webaim.org/resources/contrastchecker/.
    • Normal text – Below 24px at normal (400) font weight or below 18.66px at bold (700) font weight must be in minimum ratio of 4.5:1. Government sites must comply with a ratio of 7:1.
    • Large text – 24px or larger at normal (400) font weight or 18.66px or larger at bold (700) font weight must be in minimum ratio of 3:1. Government sites must comply with a ratio of 4.5:1.
    • Icons – All icons should have a minimum ration of 3:1, regardless of size. One possible exception to this is for icons that are labeled with descriptive text on screen, provided the text complies with contrast requirements.
    • Form inputs – Form elements like text inputs, radio buttons and checkboxes must have a minimum contrast ratio of 3:1.
  • Is meaning conveyed by something other than color? Avoid using color as the only method of conveying meaning. If the page were displayed in grayscale, would the meaning of all elements be discernible? As examples, anchor links should be underlined or visually marked and not rely on color alone and error messages should contain an error icon rather than using red text alone.

Images

  • Do images have alt attributes? Images must be able to provide a description as an alternative (alt) to being able to visually see the image. Alt attributes should be short but as descriptive as possible. For an image showing a house on a hill, the alt attribute could be written as “house on a hill” but a better, more descriptive version would be “white house on a hill in summer”. For images that contain text, the alt attribute should contain that text verbatim.
  • Do decorative images have null alt attributes? There are use cases where providing an alt attribute makes understanding the page more difficult and should be avoided. In these cases, the alt attribute should be written as a single space, alt=“ “. It is further recommended that any images with a null alt attribute also receive a role=”presentation” to indicate to some screen readers that an image has no meaning to a spoken version of the page. Note, images marked presentation should never contain alt text.
    • Images that appear alongside text that adequately describes the image. For example, a pet web site that contains a list of dog breeds, displaying a photo and name for each breed, should use null alt attributes on the breed images because it would be redundant for a screen reader to read the image alt text followed by the textual name.
    • Similarly, a null alt attribute should be used for an image when it is accompanied by a description caption or when the text of the page fully describes the image. In these cases, it is better to rely on the written text.
    • Images that are used solely for artistic and or visual ambiance but have no meaning to the page. If, for example, an image is used by a designer to add interest but can be removed from a page entirely without changing the meaning of the page, it can typically carry a null alt attribute.
    • Images that are part of the interface but convey no meaning. With modern site styling, these types of images rarely appear in sites.
  • Are graphs or charts fully described or displayed as datapoints in the content of the page? Graphs and charts (or other complex images) should provide a written description or an alternative version of the data. For example, a bar graph should provide the same data in a table as an alternative method of understanding what is depicted visually.

Forms

  • Are all inputs associated with corresponding labels? Every input in an application should use a for / id pairing where the input receives a unique id and a label is associated to it with a corresponding for attribute.
  • Do groupings of related inputs use fieldsets and legend elements? Contain groups of related inputs in a fieldset and provide a legend element to declare the purpose of the group. For example, a mailing address may have multiple inputs such as Street Address, Suite/Apartment Number, City, State, and Zip Code. These inputs should be contained inside of a fieldset element that contain a legend=”Mailing Address” to indicate the inputs are part of a larger whole.
  • Is focus state visible on screen? When interacting with forms, the focused element should be visually apparent on screen.
  • Is error messaging displayed as a complete listing at the top of a form after submission? Errors contained in a form should be displayed together at the top of a form in a single list for users to have a complete understanding of all issues in one location.
  • Are individual fields understood to be in an error state? Individual fields should be declared as being in an error state by associating an input with an error message using aria-describedby and marked as invalid using aria-invalid=”true”. More on ARIA attributes later.
  • In addition, fields in an error state should provide visual indication, including color change and/or error state icon. Remember, color should not be the only means of conveying information.

Media and Animation

  • Does media only play when started by the user? Video and audio elements should not autoplay in an application.
  • Can all media be paused? Media must support the ability to pause. For keyboard users, the SPACE key must provide the expected pause behavior.
  • Are all controls appropriate and understandable? Media controls must use the most appropriate markup for controls. For example, input type=”range” would be the most appropriate markup for a volume slider since volume can have a range of values from zero to maximum. In addition, a user must be able to understand the purpose and intent of all controls, including the state in which those controls exist. When working with media it is best to consult documentation specific to building accessible controls.
  • Do video elements provide closed captioning? All videos that contain audio should be captioned.
  • Do audio elements provide transcripts? Written transcripts should be provided for any audio files contained in an application as an alternative means to understanding the contents of the audio.
  • Can users remove animation? Animation within an application must have the ability to bee completely disabled by honoring a user’s browser-based “reduced motion” setting.

Keyboard Input

  • Can the application be used via keyboard input alone? All elements of the application should be navigable and functional using standard browser-based keyboard control without the aid of a mouse or touch screen. For example, pressing TAB on a keyboard should move to (focus) the next navigable element on screen.
  • Is focus state visible on screen? When using TAB to navigate, the focused element should be visually apparent on screen.
  • Does focus order match visual layout? Moving through interactive elements via keyboard should match the same order they visually appear on screen from top to bottom, left to right (provided left to right is the natural direction of the application’s declared language).
  • Are all invisible elements incapable of receiving focus? Users should not be able to move focus to an element that is meant to be hidden or inactive. For example, inactive dropdown menus or inactive modals should not be focusable to keyboard users.
  • Is a skip link provided? Provide users with the means to bypass blocks of content that are repeated from page to page like the site’s header and primary navigation. Typically, a skip link is exposed as the first TAB keypress on a page to provide users a means to skip to the main body of the content. Skip links may be used in different ways or locations depending on an applications design and purpose.

ARIA

As mentioned, this article will not cover specific of ARIA implementation in detail and more information can be found at https://www.w3.org/WAI/standards-guidelines/aria/.

However, ARIA provides additional information to the browser through a set of attributes that are specifically designed to support accessibility and assistive technologies. When used in conjunction with the methods above, ARIA provides supplemental context and understanding about web applications that HTML alone cannot support.

In general terms, the ARIA you add to the page should be looking to define the following:

  • All page structure - What elements are headers, main contents, navigations, sidebars or regions of a page?
  • The state or change of state for all elements - Are accordions or dropdowns open or closed? Is there a dialog open? Has something on screen changed content?
  • Role – What elements are acting as a headline, button, tab, search box, slider or menu? This is especially needed when elements are acting in a way that the HTML doesn’t intuitively provided based on the tag used.
  • Relationships - When elements rely on other elements, are their relationship or connection defined? For example, is the button that opens and closes a dropdown defied as the elements that controls the dropdown?
  • Names – Are elements named that a screen reader or other technology can read? For example, when arriving at a site’s navigation, does it have an attribute that specifically names it “Main navigation” or something similar?
  • Descriptions – Like name attributes, does all content describe its function either by text in content and context or specifically added via ARIA?

Testing

While developing accessibility applications using the approaches above, it’s important to test your end results. It’s often easy to add markup or ARIA that is interpreted by assistive technologies differently than might be expected. At a minimum, there are 3 areas to test for critical breakdowns:

  • Screen reader – Use a screen reader such as JAWS, Apple VoiceOver, NonVisual Desktop Access (NVDA) or Google ChromeVox to ensure that everything in the application is read or announces and that the full context and description of all elements are clear.
  • Keyboard input – Test all aspects on an application using keyboard access alone. Ensure that every element is navigable and interactive. Any area or function a user can complete with a mouse or touch screen should be accessible via keyboard and standardized elements such as forms should use the browser’s default keyboard control.
  • Accessibility audits – Check the state of your application’s accessibility any time there is a change or new feature added with tools such as Google Lighthouse which will scan pan your page, report an overall accessibility score, and provide information on problem areas. Just be mindful that tools such as Lighthouse do not test all areas, such as keyboard input, which must be tested manually.

Conclusion

Accessibility is important. It’s important to your users, to your customer service, and can even protect you from litigation. If you understand the importance of accessibility but need help implementing best practices and getting your application complaint with WCAG guidelines, contact us today.

The JBS Quick Launch Lab

FREE 1/2 Day Assessment

Quantify what it will take to implement your next big idea!

Our intensive 1/2 day session will deliver tangible timelines, costs, high-level requirements, and recommend architectures that will work best, and all for FREE. Let JBS show you why over 20 years of experience matters.

Get Your FREE Assessment