Skip to content

Web Design & Accessibility

Jump to bottom
Taylor Snead edited this page Aug 23, 2022 · 3 revisions

Accessible Design

Accessibility has proven to be a sticking point for developers getting oriented on the front-end of this project. Accessibility is commonly overlooked or insufficient partly because it has a broad definition: easy to access and use for people of all abilities. On the web, basic things to consider are using the relevant ARIA tags, making all information/functionality accessible by both keyboard and mouse, and ensuring high contrast.

Tips & Resources

  • Avoid tooltips unless you really need them. When you do use tooltips, make sure they provide only supplementary info.
  • Consider how someone could use your interface with only a keyboard (no mouse)
  • Consider how someone could use your interface with only a mouse or touchscreen (no keyboard)
  • Web Accessibility Checklist: This one is a bit long and it covers standard accessibility requirements well. Colors and labels are important, but it is way more than that. Answers the questions:
    • "What makes a web page 'accessible'?"
    • "What guidelines should I follow to meet foundational web accessibility standards?"
  • This blog post about accessible color schemes has links to a bunch of tools and mentions a few of the basic guidelines, like "Don’t use color as the only visual means of conveying information"
  • Color Review: Find accessible color combos, which is based on text+background contrast and font size.
  • Colorblind Web Filter: See a website through different types of colorblind eyes.
  • Material Design: Solid resource to consult for foundational web design guidelines. Answers the questions:
    • "What kind of UI elements are commonly used?"
    • "How might I lay out a web page?"
    • "How should elements be spaced out?"
    • "How does the shape of each element express the hierarchy of the page?"
  • Basic web inspector tutorial: I use the web inspector to do simple experimentation of page layout, colors, and fonts on an existing website.
  • Typography.js: Use the toolbar on the right side to test out combinations of fonts, vertical rhythm, and other typographic parameters. We use this framework internally, so we can adapt parameters tested there directly.

UX Design Process

  • Start designs in grayscale (or minimal coloring) when possible. When getting conceptual or functional feedback, use only black/white/gray so that your audience isn't distracted by colors but focuses on the shapes and concepts instead. Then later on, when the concept is solid, add color.
  • Everything must ultimately be vector rather than raster. All logos, icons, and design prototypes should be vector .svg files. For the final product, this is necessary. For prototypes that need evaluation and feedback, using grayscale vectors reduces distractions. I use raster (like drawings on paper) for initial drafting/sketching before any phases of feedback.
  • When possible, bring many different prototypes (and past versions of your favorites) to feedback sessions for your collaborators to be able to compare. This gives them more opportunities to give constructive feedback, because they can say "Well, I like this part of this one and that part of that one," etc.
  • A web logo should be easily simplified into an icon, for use as a favicon or mobile app icon. This means no more than 3 colors, less intricacy, and high recognition (i.e. specific).
  • Generally avoid using icons where possible, because using text is often clearer. However, if you must use an icon, then prefer to use the Material Design collection of react-icons, and prefer to pair it with a label. We prefer Material Design icons simply because there is a large selection of them, providing us with a consistent aesthetic.
  • Always make a mobile design, and keep low resolution devices in mind for any design. Plenty of Cherokee folks have limited internet or device access and may be restricted to a mobile device. The majority of web access in general is now on mobile devices, especially among poorer groups in the U.S., so excluding a mobile design could ultimately be a discriminatory practice.

Accessible Implementation

In general, we use Reakit to build React components. Reakit has several granular building blocks that handle basic accessibility concerns like focus management and screen-reader labeling. It also has higher level building blocks for things like modal dialogs, tab panels, and menus that are immediately more accessible than what we might build from scratch.

Styling and Events

You may run into scenarios where a particular interaction could be implemented using either JavaScript or purely with CSS. A good mantra to follow is:

If it can be done with CSS, then it should be done with CSS.

We stick to this philosophy because CSS is wicked fast and vanilla-extract provides us with powerful styling tools that incur no runtime performance loss compared to vanilla CSS. Look here to get a basic feel for how styling with vanilla-extract works.

Hover

If you need to style an element based on its hover state, use the CSS :hover selector. However, most importantly, always use the hover media query along with it. Any hover styling you have should look something like this:

@media (hover: hover) {
  a:hover {
    background: yellow;
  }
}

This prevents weird styling behavior on mobile, where using :hover without the media query would result in such styles being applied when you tap an element. Generally speaking, this isn't what we want and leaves users with the impression that there's an emulated mouse controlled by their taps. Instead, we want our default styles to always apply on devices which don't have hover capabilities, like mobile devices. Then, on those that do, like the desktop, we have specialized :hover styles.

Clone this wiki locally