Accessibility

We aim to provide the best possible experience for all users without regard to their permanent or current abilities. We achieve that by following WCAG 2.1 level AA standard when designing, coding and writing content.

Lighter provides accessible components ready to be used in your web projects. You'll find accessibility documentation bundled with every component - whether it follows WAI-ARIA authoring practices or not (and why), what to keep your eye on and whether it's been tested.

When writing your own components or building larger chunks - patterns or whole screens - start by making sure that you follow the Four Principles of Accessibility.

Colors and contrast

Users use their devices in non ideal conditions all the time. To ensure readability in direct sunlight, on a dim screen or for a person with not exactly 20/20 vision, the text must be in contrast with the background. WCAG level AA requires at a contrast ratio of at least 4.5:1 for default font sizes and 3:1 for large sizes (18px bold and 24px regular).

Read more about colours and contrast Accessible color combination tool

Use native HTML5 elements

No ARIA is better than wrong ARIA. Whenever you can, use native HTML5 elements - when used correctly, you get accessibility for free. A quick note on buttons and links: buttons do stuff, while links (anchor elements) take you somewhere. If the href attribute equals #, you should probably use a <button>.

How to use ARIA in HTML

Keyboard navigation

Each interactive element must be reachable and operable by keyboard. Be careful when creating clickable variants of non-interactive components. Although they might look similar, the markup has to be different.

When creating interactive widgets, head straight to [https://www.w3.org/TR/wai-aria-practices-1.1/](WAI-ARIA Authoring Practices 1.1) - when none of the suggested design patterns match your needs, you should probably consult with designers. Consistency is key and users probably won't be able to use your custom widget, as they haven't used it before.

Beware of copying the authoring practices to the point. Some of their specifications for interactive widgets, such as menubar or window splitter are meant for desktop apps.

Focus rings

If you can click it, put a ring on it! Focus rings identify elements which are currently in focus. This is tremendously important for keyboard users - they don't have a mouse cursor and rely on it heavily.

While setting outline: 0 globally is considered blasphemy, designers and clients often demand this. As compromise, you might turn off focus rings for mouse and touch users on elements which don't expect keyboard input. Inputs, checkboxes, radios, etc. should always display a focus ring when focused.

Labels, labels, labels.

Structuring content

HTML5's outlining algorithm was supposed to support using any heading level in sectioning elements (section, article, aside, nav…). In reality, there are currently no known native implementations of the outline algorithm in browsers or assistive technologies. Therefore, always use correct heading ranks (h1-h6) to convey document structure.

Creating an outline

Each document should have a main section, usually declared as <main role="main">, for better support in browsers and assistive technologies. In addition, a <header role="banner"> is recognised as the "header" area of the website, usually consisting of a logo, navigation, and sometimes additional features such as search.

Take care when creating sectioning components. The <section> element has its own semantic meaning, and should not be misused for presentational purposes. Each sectioning element (section, article, aside, nav) should be labeled with a heading or aria-label.

Headings and sections

Testing for accessibility

Disconnect your mouse, dim your screen (turn it off completely) or set zoom level to 1200%. Then try to navigate and operate what you just built. Not so easy heh?

Keyboard operation

Check if you can interact with the website. Pressing the Tab key should highlight the first interactive element in order. If you can't determine your position, you are either missing focus rings or there is a visually hidden element, which can be interacted with using a keyboard.

Interactive widgets are often operated with arrow keys (tabs, menus, etc.). Check the [https://www.w3.org/TR/wai-aria-practices-1.1/](WAI-ARIA Authoring Practices 1.1) if your widget behaves the way it should.

Pressing ESC should close any open dialogs, tooltips, dropdowns, or any other elements that overlay a portion of the website.

Screenreader testing

A screenreader reads everything aloud, allowing users to navigate the website without the need of a display device. You should test whether screenreaders understand your markup and convey meaningful information to users.

If screenreader accessibility is key to the success of your site/app, you should test with as many screen readers as possible.

Automated testing

Automated tools can reveal issues with color contrast, missing labels, incorrect document outline and many more. Lighter already checks for many accessibility issues when linting, but can't cover everytthing.

Pick your favorite tool - for example WAVE, Lighthouse or Accessibility Insights and let technology do the work. You'll have to fix the issues manually though.

Lighter

    v1.0.0