Creating Accessible Websites

Our work with Higher Education, Government, and large enterprise clients require us to think about all the different users and visitors to websites. This typically also includes requiring our products to be accessible for visitors who have a need to browse the websites in an alternative method. Even if you are not a government entity that has been required to be accessible, the ongoing trend of law firms sending letters to essentially hold you hostage for a quick settlement with a threat of time in court has been increasing:

While many of these complaints have been rejected when met in court, ( it's best to just make sure you have your site reviewed.

To make sure that there is consistency for these alternatives to using, there is the W3C who manages the web content accessibility guidelines, also known as the WCAG.

The WCAG is the standard for online web accessibility and as a stable and usable technical standard, we can develop sites to a 2.0 AA standard that supports the needs of most visitors using alternative browsers. You can learn more about the requirements here: 

Some of the standards we use are:

  • WCAG 2 (more stringent) on a scale from less to more stringent (A, AA, AAA)
  • ATAG 2 (for authoring tools like WYSIWYG, CMS)
  • ADA Section 508 (less stringent) 

When we talk about accessibility it's easy to confuse or over thinks what may be required and create work that may be unnecessary to what is required. That's why standards were created to ensure that we meet the requirement and that it's usable by all people while capable of still providing a great design. 



  • Provide text alternatives for non-text content
  • Provide captions and alternatives for audio and video content
  • Make content adaptable and make it available to assistive technologies
  • Use sufficient contrast to make things easy to see and hear


  • Make functionality keyboard accessible
  • Give users enough time to read and use content (example: slideshows)
  • Do not use content that causes seizures
  • Help users navigate and find content


  • Make text readable and understandable
  • Make content appear and operate in predictable ways
  • Help users avoid and correct mistakes


  • Maximize compatibility with current and future technologies

This helps these specific disability types:

  • Vision impaired - blind, low-vision, color-blind
  • Deaf and hard-of-hearing
  • Motor
  • Cognitive
  • Seizure

For notes on design accessibility, you can click over to our "Making Accessible Designs" article.

Our internal accessibility experts review our design and development of any platform to adhere to the standards required in our contracts. Some of the tools we use are: 



Server Based:

Browser Extensions:

OS Features:


We will continue to change and expand on the below, but it is some of our criteria and tools used to implement accessible options for sites.

Form Inputs:

  • All controls and inputs should have labels that are descriptive or a fieldset if labels are not applicable
  • Instructions are provided where necessary
  • Errors are described to the user in text
  • Include a name, role, and value
  • move focus to the input with an error when it has one
  • use html5 types and patterns

Use jQuery validation:

Captcha Spam Control on Forms:

Captcha should provide alternatives for people with various disabilities or be accessible. 

General Site Functionality:

  • All functionality should be operable through the keyboard.
  • All links and form inputs should allow you to tab/arrow to and away from them, in an order that preserves meaning and operability
  • Timed events like slideshows or log out popups should provide a way to extend or stop this with the keyboard
  • Any scrolling, moving, auto updating or blinking mechanisms should be able to be paused or hidden with the keyboard
  • do not flash more than 3 times per second as this can cause seizures
  • there should be a way to bypass content that is repeated on multiple web pages (skip to nav, skip to content links)
  • All links purpose can be determined by the link text alone, or with the context of its containing a paragraph, table cell, or list.  Make line-by-line reading sensible. 
  • There is more than one way to locate a web page within a set of web pages unless it’s part of a process
  • the keyboard focus is visible in some way at all times
  • there is a breadcrumb or other way to tell where you are on the site
  • the header tells us what written language the webpage is in
  • HTML is correct, do not contain duplicate attributes, ids are unique
  • Any javascript has text identifying what the script does in no script tags
  • any application required to view a pdf, applet, plugin, etc is provided in a link on the page (can be a link to a single page linking off to tools)
  • Document the user interface, including all accessibility features
  • Data tables have column and/or row headers appropriately identified (using the <th> element).
  • Data table cells are associated with the appropriate headers using the scope or id/headers attributes.
  • Each frame is given a title that describes the frame's purpose or content.
  • Don't write scripts that require mouse usage. Supply keyboard alternatives (e.g. use onFocus instead of onMouseover).
  • Lists should never be used for merely indenting or other layout purposes. Nested lists should be coded properly.
  • The viewport must allow users to pinch zoom (scale) up to 200%.
  • Have links to pdf readers and any applications needed to view things, could be a single page with a bunch of links that are linked to. 


  • Use an inline SVG
  • Have a role, title, text, description, and text alternative
  • Use links so they’re focusable with tab

Heading Elements:

  • The page has a title that describes its topic or purpose
  • All headings describe the topic or purpose
  • section headings are used to organize content and are in an order that shows this organization
  • Headers used for organization, not appearance 


  • Provide alt text, unless decorative or linked (with text on the link)
  • keep alt text small and to the point, and only for images that matter
  • Use real text rather than images of text unless it is a logo
  • use longdesc to describe complex images or link to pages of description

When using a background image, use aria labels
<div class="hero img" role="img" aria-label="Snow storms on the horizon">
    Snow storms on the horizon


  • Provide a text description of the video
  • Provide captions or have transcript that it is labeled relative to if it’s pre-recorded
  • There is a pause/play button and a volume control
  • Unless it is music, captcha, or a logo there must be no background noise (or are 20db lower than foreground noise), or the background sounds can be turned off 

Text Elements:

  • All text can be resized to up to 200% without a loss of content or functionality using the web browser zoom.
  • Make sure that links make sense out of context ("click here" is problematic).
  • Don't write scripts that require mouse usage. Supply keyboard alternatives (e.g. use onFocus instead of onMouseover).
  • To reduce that amount of horizontal scrolling, use relative rather than absolute units (e.g., use percentages for table widths, instead of pixels)
  • Write clearly and simply
  • Do not use text formattings, such as font size or bold to give the visual appearance of headings - use actual heading (<h1> - <h6>) for all content headings.  Likewise, do not use headers to achieve visual results only.
  • Include :focus and :active on your hover states 

AAA Text (Typically not required):

  • Line spacing (leading) is at least space-and-a-half within paragraphs, and paragraph spacing is at least 1.5 times larger than the line spacing.
  • Foreground and background colors can be selected by the user.
  • Width is no more than 80 characters.
  • The text is not justified (aligned to both the left and the right margins). 

Also, see our list of examples and code to use >