Best Practices for Accessibility in Web Design

Providing a good user experience means making sure a design is accessible to all users.

At build/create, we believe that the rules that govern both beautiful, functional web design and accessibility have a lot in common. Our sites prioritize functionality and user experience over flashy or overly artistic designs. While these sites often seem creative and interesting at first glance, they also cause a high number of problems for all users—and especially those who are already underserved by exclusionary web design practices.

Although we are a small team, our designers and developers are aware of accessibility best practices. We structure our content with the appropriate HTML codes to make them compatible with assistive technology, and we perform UX/UI testing to discover any usability or accessibility problems prior to launch.

We are also quick to respond to any accessibility issues that are brought to our attention after launch. However, following best-practices during the development process has virtually eliminated complaints about accessibility on our sites.

The following is a review of accessibility best practices we handle during our design process.

   Visual.

Users with visual impairments include those with blindness, colorblindness, and weak vision. While some users may be able to see well enough to find information on a screen, others rely on assistive technology to navigate.

Best practices for visual accessibility include:

  • Site architecture is compliant with screen reading devices.
  • Images include alt tags.
  • Headers are descriptive and formatted using header tags.
  • Links have descriptive anchor text.
  • Design elements employ sufficient white space and contrast.
  • Designs do not rely on color coding alone to communicate information.
  • Design elements do not move unexpectedly.
  • CAPTCHA include non-visual options.
  • Forms include labels and are compatible with screen readers.
  • Design is responsive to magnified browsers.

  Auditory.

Most websites are not, primarily, an auditory medium. However, websites are increasingly incorporating audio/visual components, which must be treated differently depending on if the audio is live, pre-recorded, or designed for users with only partial hearing impairment.

Best practices for auditory accessibility include:

  • Pre-recorded audio content includes subtitles and transcripts.
  • Live audio content uses closed captioning.
  • Audio is clear and does not include background interference.

  Motor Control.

Those struggling with motor control difficulties range from users with a slight tremor which may make it difficult for them to click on a button, to users who are paralyzed or otherwise incapacitated and rely on either speech commands or keyboard navigation to access a website.

Best practices for motor control accessibility include:

  • Site architecture is compliant with speech or keyboard navigation.
  • Buttons include enough padding to be easily clickable.
  • Elements do not move or shift unexpectedly.
  • Navigation menus do not require fine motor movement.
  • Shortcuts to complete forms are provided.

  Cognitive.

Cognitive issues commonly include users with autism, anxiety, ADHD, dyslexia, as well as any users who struggle with memory or are easily confused. Collectively, this encompasses a significant percentage of the American population.

Best practices for cognitive accessibility include:

  • Design follows a linear and logical layout.
  • Copy avoids ambiguous or overly complicated language.
  • Information is provided near to the place on a page where it is needed.
  • Instructions appear next to each step, not on previous pages only or all in one block.
  • Users can check their information before submitting it.
  • Call-to-action buttons are descriptive.
  • Error messages communicate the cause of the error.

How we handle accessibility at build/create.

The practices discussed above are part of our standard design best practices. We are also happy to discuss any specific questions you may have about these accessibility requirements during our discovery and proposal stage.

Many of our clients are small businesses with limited budgets. For this reason, our standard practice does not involve explicit testing with disabled users or with specific assisted technology. However, we are happy to include this as part of our scope of work for any organization that requires it. In such cases, we have a Voluntary Product Accessibility Template (VPAT) which we employ to structure our accessibility audits.

Additionally, all our websites are developed in a live testing environment, which we can make available for any clients who wish to test our sites for accessibility themselves.

For any further inquiries regarding our accessibility capabilities, please direct them via our contact form to Eric Lynch, our Director of Business Development, and he will be in touch with you shortly.