Web Accessibility: The Art of Being Inclusive

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.