accessibility conventions

---

tags: [a11y, conventions]

Accessibility Conventions

<style> .check-div { padding: 1rem; } .check-div > label { margin-left: 1rem; } fieldset { padding: 3rem; } h2 { font-size: 1.25rem; padding: 0.5rem; } calcite-chip { margin-right: 0.5rem; } </style>

Calcite Components leverages the W3C Accessibility Standards to ensure the applications and experiences are usable by a wide range of audiences. There also pages for accessibility-design-conventions and accessibility-developer-conventions. Additional considerations in designing for individuals include:

Designing for Individuals	Do	Don't
On the Autistic Spectrum	Use simple sentences and bullets.	Create a wall of text.
Who use Screen Readers	Write descriptive links & headings.	Write vague links & headings.
Who have low vision	Use a combination of color, shapes & text.	Use only color to convey meaning or status.
With physical or motor difficulties	Make large clickable actions.	Demand precision.
Who are deaf or hard of hearing	Use subtitles or provide transcripts for video.	Put content in audio or video formats only.
With Dyslexia	Provide reminders & prompts.	Force people to remember things from previous places.

# Checklist

Content

Information should not depend on color, sound, shape, size, or visual location Design

Text and background color should have sufficient contrast Design

Links should be descriptive and provide intent Design

Links should be visually identifiable Design

Use descriptive section headings Design

Content should use semantic HTML elements Development

HTML should be valid and error-free Development

Forms have descriptive labels Design

Forms have helpful and accessible error and verification messages Design

Labels and help text should be programmatically associated with form fields Development

Use correct HTML5 input types Development

Content does not loose context when zoomed/enlarged Development

Site should not time out unexpectedly Design Development

Pages are understandable with no styles enabled Development

Web page size should not exceed 500k Development

Keyboard & Assistive Tech

Users should be able to navigate content using a screen reader Design Development

Avoid mouse only interactions Design Development

Support keyboard navigation Development

Focus states should be visible for keyboard users Design Development

Allow keyboard users to skip navigation Development

Offer multiple ways to find pages on your website Design

Use ARIA landmarks where applicable Development

Set focus on modals, popovers, alerts, etc. Development

Multimedia & Data Viz

Images should have meaningful alternative text or intentionally marked decorative Design Development

Decorative images should not be visible to screen readers Development

Content that moves automatically has the ability to be paused Design Development

Limit or remove any flashing elements Design

Ensure audio and video is not played automatically unless that is the expected behavior Development

Multimedia should have alternative ways to be consumed Design Development

Make data available for graphs, charts, maps, SVGs, etc. through assistive technology Design Development

Table data is accessible to non-sighted users Development

Renderring SVG elements within components

SVGs are visual elements. When rendering them in a component, assess if the SVG has semantic meaning that needs to be described.

If the SVG has no semantic meaning or the semantic meaning is described elsewhere, make sure to set aria-hidden="true" on it so that screen readers can ignore it.

If the SVG has some semantic meaning that needs to be described to an end user, set the role to img and ensure that it has an aria-label or aria-lablledby.

More information can be found here: https://www.deque.com/blog/creating-accessible-svgs/