Inclusive & Accessible Design


W3C’s Web Content Accessibility Guidelines provide the basis for making web content accessible for people who have all different types of sensory and cognitive circumstances.

In a corporate environment working with a lot of different project teams there are always competing expectations and needs. In certain instances there is a contractual requirement like Section 508 if you are working on a Federal contract.

It can be hard to get started on Inclusive & Accessible design if you are only considering it after you have already built your product or site. The Web Accessibility Initiative (WAI) is a working group of W3C which provides fantastic resources for getting started. One of the first resources I send project teams asking about “What is most important” or “Where do I start” is the “Easy Checks” resource:

Where Do I Begin with Accessibility?

The WAI “Easy Check” highlights some of the really common issues that are typically some of the most straightforward to integrate into a web project.

Page Title

This may seem pretty straightforward. However, be careful in the case of some frameworks like Angular this is not as straightforward as it seems.

In my page here WordPress does a reasonable job of adjusting the Page Title (which reflects on the browser tab).

Screenshot demonstrating browser tab title here with the text: "Portfolio - Andrew's Site"
Screenshot demonstrating browser tab title here with the text: “Portfolio – Andrew’s Site”
Screenshot demonstrating browser tab title here with the text: "About Me - Andrew's Site"
Screenshot demonstrating browser tab title here with the text: “About Me – Andrew’s Site”

Angular on the other hand tends to have single page applications that do not update the page title based on where navigation is on the single page application.

Page Title is particularly important for people who are using assistive technology like screen readers. This helps orient them where they are in the structure of your page. Having appropriate page titles should be designed as part of your initial page design when you are constructing your page information architecture and general page hierarchy.

Alternative Text (All Non-Text Content)

Alternative text can be one of the trickier items to be fully compliant. There are a few major issues:

  • Where do I need alternative text
  • What does the text need to be?
  • Appropriately applied NULL tags to decorative elements

There are automated checks available via Chrome Devtools (Google Lighthouse) and WebAIM’s WAVE Scanner plugin. It is important to remember that automated scans can only discover IF tags exist and not the quality that they are.

WAI again has great resources on how to develop appropriate alternative text. WebAIM also has a fantastic resource on alternative text methods. However, on the IT side there are accessibility needs but these need to extend over to content developers. Someone producing a video file also needs to produce a video script (at minimum) and to meet WCAG 2.1 AA captioning for the video.

Headings & Structure

Headings & Structure provide the general outline of how information will flow on your site. For a sighted individual it is not often hard to discern (or develop on the fly) a basic hierarchical understanding of structure. However, a blind user who is using a screen reader or other assistive technology will benefit greatly from a well-defined page structure.

Ensure that H1 is only used ONCE per page. H2, H3, and H4 should be used hierarchically to define subareas and subareas of those subareas. Also make use of HTML5 landmarks to help screen reader users navigate your site.

Contrast Ratio

A lot of sites do not meet compliance on this guideline. The WCAG 2.1 AA requires a contrast ratio of 4.5:1 on the difference between background and foreground colors. A lot of times sites at a glance will look compliant but will be JUST out of compliance.

A common design trend is to not use pure black (HEX #000000) text. But rather to use more of a grayish text. I have heard some project members mention that they feel the black text is too stark and like the lighter gray text as it “softens” the page. There is plenty of psychology of design and color theory that can be discussed around the effects that color has on emotional context and user perception. The bottom line though is all of that psychology isn’t valuable if a user is unable to ascertain the actual content behind a low contrast color combination.

You do not need to stick to straight black and white to be accessible. You can still use color you can still use different contrasting colors. As a designer you will just need to be more mindful of how those contrasts appear to folks with low vision.

It is also important to remember people who have color blindness. With the explosion of data and the love for applications like Tableau and other data visualizations we have seen a return to a lot of usage of color alone to indicate differences. If you take nothing else away from color blindness considerations in the development of any sort of non-text element remember: NEVER USE COLOR ALONE TO INDICATE. Always have text or a shape or SOME other method of indicating a difference so as not to rely on color.

Resize & Reflow

If you’ve worked with users who have lower vision or impaired vision the importance of Resize & Reflow becomes immediately apparent. I have conducted usability studies with users who needed to zoom in the application greater than 200% to be able to see. Part of this was poor hardware ergonomics (they had a poor resolution monitor). The other part is the tendency for sites to default text to pretty small font sizes.

Ideally, a user should be able to zoom your site, but in addition to being able to zoom also have the text reflow to still make sense. The site needs to still be USABLE even at 200% zoom without having obnoxiously large horizontal scroll bars and elements blown off the page.

Keyboard Access

Try navigating your website using only your keyboard. Can you access every element? Can you tell where your “cursor” is located? This is a quite a common issue that comes up in a lot of accessibility evaluations. Sometimes certain navigation elements are inaccessible via keyboard. Keyboard access is paramount to a screen reader who will be navigating your site purely with their keyboard. They need to be able to access every relevant element on the site.

Additionally, having visible cursor indication tab helps orient those who may be using assistive technologies and need to know where their active cursor element is on the screen.

Forms, Label, and Errors

Make sure that all forms are accessible by keyboard only. You should also opt for text labels on forms to help screen reader users understand what information the form is asking them to enter. This can either be done at the programmatic level or as an actual text label. With certain custom buttons and elements, it’s important to add ARIA tags so that a screen reader can announce what the purpose of that button is and where it’ll take the user.

Along with this is important to remember how you are labeling links. Links should be informative of where the link is taking someone. Sometimes just a “Click Here” link can be difficult to understand what link is doing. Sometimes the surrounding text provides enough context, but sometimes it doesn’t.

Moving, Flashing, or Blinking Content


Well, ok. You can use motion but be mindful of how QUICKLY the motion moves. It is best to provide the capability to pause any sort of motion or animation.

For any flashing or blinking content remember that the WCAG requirement is to not have anything that blinks faster than 3 times per second as it can trigger epileptic seizures.

Motion can be a powerful tool for drawing attention, but TOO much motion can make your users feel sick or disoriented. So again be MINDFUL of how to use motion. Ultimately, you want the user to be able to control things like motion and animation to suit their needs. Take a look at the W3C guidance and the CSS reduce-motion.

Comments are closed.