Ensure Web Pages are Accessible

Building pages for accessibility from the ground up future-proofs web pages against impaired user issues. A few years ago a large national retailer was involved in a large law suit due to their web site having impaired user accessibility problems – users who are blind or due to disability cannot use a pointing device. Getting our clients’ content to everyone regardless of disability – even if you consider that disability to be Internet Explorer or Edge – is my job, and I take that task very seriously.

Although my final code is based in the original WAI, I usually go over a quick list like this one. Here are the elements guaranteed in any pages I publish.

  • Valid Pages. As discussed in the blog post Why Validation Matters, valid web pages are the foundation for any page output.
  • Use the alt attribute on images. The alt attribute was one of the first accessibility considerations, providing contextual content for users who could not see images. I use them religiously, they are required for valid pages. For empty images, such as spacers or background tiles (who uses those any more!) the alt attribute can be empty but it must be present. It’s also a great opportunity to leverage making your page SEO Friendly.
  • Implement Skip Navigation Links. One of the requirements of WAI that is often overlooked is the ability to skip navigation links. If you set aside your mouse and navigate this site using only the Tab key on your keyboard, you will notice as you approach navigation links, a "skip navigation" link comes up. Press enter when it does, it will bring you to the next content block. These skip the top nav to content, then sidebar links to the bottom links, then bottom links back to the header. I expand on how this site does this in the blog post Creating Skip Navigation Links.
  • Color Contrast Check. Even before I started wearing contacts, some of the Web 2.0 sites I visit have such a low text to background contrast that not even I can read them. Imagine the pain if you are color blind. One of the guidelines is to avoid low contrast color schemes and ensure you content is legible to all users. Early on in the design process I check my color schemes against a tool such as this one. Keep in mind acceptable contrast is a matter of degree, if it fails horribly, I rethink the color scheme.
  • Text must be resizable by the user. Users must be able to resize text at least up to 200%. I always use a dynamic unit such as em or percent to style web page text, which allows resizing naturally based on the operating system and browser. I never use px for text sizing except in rare or relatively unimportant cases where the text absolutely must match the size of an element that is defined in pixels. This plays a part in coding to the natural flow of the document.
    Many of these widgets were later incorporated into HTML5, and developers should prefer using the correct semantic HTML element over using ARIA.
    MDN Web Docs
  • Semantic HTML over Aria Elements. Prior to HTML5, Aria Elements were required to provide context for page elements so screen readers would understand the intent of the element. A perfect example (which I came across developing this site) is the <nav> element. WordPress still adds the role="navigation" attribute to <nav> elements. When I validated the pages, the validator complained that role="navigation" was redundant for the <nav> element. It was only a warning and not an error, but right is right, see how I hooked it out here.
    As the inset says, if you make a habit of coding in semantic HTML in HTML5, you generally don’t need Aria elements. It’s less work too!
  • Test for accessibility. This part of my development cycle is fairly straightforward and takes two forms.
    • Set aside the mouse, navigate a site using only the tab, enter, and other keyboard input (Resist the urge to reach for the mouse!) Can the page be navigated by keyboard only?
    • Navigate the site in a screen reader, such as JAWS or NVDA (also by keyboard only.) As you navigate the page, the screen reader should be able to clearly describe where you are in the page and expected content.

Accessibility considerations are just another aspect of how I develop sites. It is not an optional add-on or additional feature, it is an integral part of my development cycle.