About

An accessible product is designed and developed in such a way that all users, regardless of ability, can perform the same actions and access all information across the product. People interact with technology in varying ways, like navigating by keyboard and not using a mouse, or by using a screen reader to interact with the product, so it's important to design and develop with all users in mind. As you are writing components or developing features, you can make it accessible for everyone by checking the component against the following guidelines.

Keyboard Support

Make sure all functionality available by mouse and touch is also available by keyboard. This means all actionable elements, like buttons, links, and form fields, can be reached, interacted with, and triggered using the keyboard.

Focus Management

Also keep in mind that keyboard users should have a clear sense of where they are on the page, so be sure to include prominent focus states for any actionable elements.

Similarly, ensure that the user's focus is logically placed during and after certain interactions. For instance, when a user opens a Dialog, their focus should be placed on a logical, focusable element within the Dialog, such as a close button or the first input. Then, when the user closes the Dialog, their focus should be placed back on the element that triggered the Dialog.

Headings

Headings should be used where appropriate, like to label ensuing sections of content. Statements and straplines are not headings. Nesting the heading structure is important, so try to use the correct heading levels for the content. For example, in a section beginning with an <h3>, an <h4> would label a subsection, and another <h3> a sibling section. There should only be one <h1> per page/screen.

Color

Contrast

Contrast between the elements on a page must be sufficient in all cases. Contrast ratios between text and icons and their respective backgrounds should always be above the WCAG recommended threshold ratio of 4.5:1 for standard or small text and 3:1 for larger text.

Conveying Meaning

Color should not be the sole mechanism used to convey meaning. For example, a red border used to convey the presence of an error needs to be accompanied by a symbol, such as a warning icon, or text, such as 'This field has an error'.

Image Alternatives

Make sure all images have an alternative text attribute. The content of that attribute will vary depending on the image's purpose:

• Decorative images: Images just for aesthetic purposes (borders, flourishes, etc) must take alt="" to remove them from screen reader output. Do not remove the alt attribute, simply keep it empty.
• Photos: Images of the Optimizely office and team members should have alternative text, but just a couple of well-written and evocative sentences.
• Interactive elements: Interactive elements using icons or the Optimizely logo need to describe their purpose, like "Preview Experiment", not the appearance of the image itself, like "Trash Icon".
• Informative images: Images that convey important information, like an infographic or chart image, should have detailed alt text describing the information being presented.

Labels

Ensure all form elements, buttons, and links, are readable by assistive technologies, like screen readers.

Forms

All form elements, like inputs, checkboxes, and radios, should have an associated label by using the for="" attribute on the label that matches the id="" attribute on the input. Fieldsets should have an associated legend.

Buttons

Buttons that do not include text, such as Icon Buttons, must have a title attribute that describes the button. For example, a Trash Icon Button might have title="Delete User Jane Doe". This makes the button's purpose clear for all users.

Links

Screen reader users can use keyboard shortcuts to get a list of all links on any given page. In order to make it clear what a link's destination or purpose is, be sure to create the link around a meaningful piece of text. For example, it's much clearer if we suggest visiting the Optimizely Developer documentation instead of asking you to go here for more info. Further detail can be added to the link by using the aria-label attribute, like when links are used to jump to a page section. Detailed links help all users, not just screen reader users, understand where a link will take them.

ARIA Roles

When developing, be sure to prioritize the use of correct semantic HTML elements whenever possible. However, if a semantic element does not exist for the component, use appropriate ARIA roles in the markup to help better describe the intent of the component and make it accessible for all users. For more information on the role options, visit the WIA-ARIA Role documentation that describes all possible ARIA roles and their use cases.