Digital Accessibility in the Buckeye UX (BUX) Design System
We have built all the components in the Buckeye UX (BUX) Design System with digital accessibility in mind. Each component has gone through a rigorous review and been coded to follow WCAG 2.1 AA Standards. Each component has gone through a rigorous review in collaboration with the Ohio State digital accessibility center[https://accessibility.osu.edu/] and been coded to follow WCAG 2.1 AA Standards[https://www.w3.org/TR/WCAG21/].
Keep in mind that once you have built your application or website you need to test it according to the Framework for Ohio State Built Products. All products must be reviewed according to the Ohio State Minimum Digital Accessibility Standards (MDAS). All but the lowest risk products (A1, 500 or fewer users) must have a Full Manual Test performed by an OSU ADA Certified Evaluator.
If you are entering a contract with a development firm to produce your product, the contract must include Accessibility Contract Language.
Here are more details on how to review an application or website for digital accessibility.
A “Skip to main content” component is included in the design system. It is not automatically added to any header or navigation components. This functionality needs to be added to the website by the developer. The “Skip to main content” component should be before all other components for it to be focuses on the first TAB keystroke after the page loads. Success criteria 2.4.1 Bypass Blocks goes into more detail about what the requirements are for this functionality.
Below are a series of WCAG success criteria and advice and reminders for how to ensure components remain accessible in real-world use.
SC stands for Success Criterion
Common Accessibility notes for content editors and developers
Images and graphics SC 1.1.1
Images, photographs, graphs, diagrams, and icons must have a text alternative unless their content is purely decorative or described elsewhere. A valid example of being described elsewhere is an icon that also has a text label. Since the text label duplicates the meaning of the icon, the icon should be marked as decorative by using an empty alt attribute (alt="")
Icons in components and UI controls SC 1.1.1
Consider icons that are part of a component or UI control. If the icon communicates redundant information, (A warning style icon with the header "warning") The icon must be hidden from assistive technologies. If the icon is the sole method to communicate something, (a magnifying glass on a "search" button), the icon must have a text alternative.
Heading levels need to reflect page hierarchy and must not be used for style or presentation SC1.3.1
Components that use heading elements must use the correct heading level. Example: If a component's sample code uses <h3> headings as a collection of subheadings, and it is placed in a content area where the nearest previous heading is an <h1>, the component must use <h2> elements so that it preserves the correct page hierarchy.
Icon fonts should use elements without semantic meaning SC 1.3.1 (and SC 4.1.2)
There are many examples on the web using the <i> element for holding an icon specified wih CSS. This is not ideal since <i> has semantic meaning. Use a <span> instead.
Disabled form controls SC 1.3.1 (and SC 4.1.2)
Disabled elements must include the aria-disabled and/or the disabled property
Include autocomplete information about the purpose of fields SC 1.3.5
Browsers may save common types of form input data about the current user (such as name, address, and email address) if the user has chosen to allow it. Developers must use the autocomplete attribute to assist users in inputting the information. See https://www.w3.org/TR/WCAG21/#input-purposes for details on which data types must have these autocomplete values.
Note about text color contrast and backgrounds SC 1.4.3
Be aware that using these components on a background color other than the BUX color palette background they were designed for will require testing to confirm interface elements and text has adequate contrast with the background used.
Images of text SC 1.4.5
Images of text should not be used unless that presentation is essential to the information being conveyed. Some valid examples are infographics, charts, logos, posters, and images of signs. Like all meaningful images these images must have alt text describing their content. More complex images, especially infographics and charts need long descriptions. Long descriptions should be visible text. Two options for implementing a long description are the Image with caption component or using the aria-describedby attribute to link a paragraph or section of text to the image.
Sufficient Color Contrast of User Interface Elements SC 1.4.11
User interface elements such as the empty outline of checkboxes must have a 3:1 color contrast ratio with their background. Changes to an interface element to communicate a state such as Active or Selected, must exhibit a 3:1 contrast ratio between the same regions in their inactive and unselected state. Hover states are not required to have any contrast minimum, however, take care to not let the hover effect cause a contrast failure elsewhere in the element. See this article from TPGi for a discussion of hover and UI contrast https://www.tpgi.com/a-whole-lot-of-bovver-over-hover/. The 3:1 contrast ratio does not apply to disabled form controls or elements.
Bypass Blocks SC 2.4.1
The intent of this Success Criterion is to allow people who navigate sequentially through content more direct access to the primary content of the Web page. Web pages and applications often have content that appears on other pages or screens. Examples of repeated blocks of content include but are not limited to navigation links, heading graphics, and advertising frames. Small repeated sections such as individual words, phrases or single links are not considered blocks for the purposes of this provision. Skip to content links are one example of a bypass block where a screen reader or keyboard only user can skip over all of the header and navigation content and go directly to the main page content. Skip content links can be used elsewhere in the page to skip over other content that would take much effort to read through, such as large data tables.
Natural Predictable Focus Order SC 2.4.3
Developers should not use JavaScript and tabindex to change natural focus order of interactive elements on the page. Exceptions are within components where focus must be managed (see "roving tabindex") and when ordinarily non-interactive elements should be added to the taborder (tabpanel example)
Links in content must convey their purpose SC 2.4.4
Developers and Content Editors must ensure that link text clearly describes the content that the link points to. If the link text is not sufficiently descriptive, the text immediately preceding the link may be relied upon to provide sufficient meaning. Examples
Clear and Meaningful Headings and Names SC 2.4.6
Ensure that the text used for headings meaningfully describes the content that follows them. Heading texts should be written so they are meaningful representation of the page when viewed as entries in a document outline.
Form field labels and control names must be understandable and have a clear meaning in their context. Name things so people will understand them.
Altering Accessible Names for Visible Text Labels SC 2.5.3
Avoid using aria-label or aria-labelledby to override the visible text of a button, form label, link or any other control. This creates a barrier for voice control users. A better way is to add text that is not visible also known as “Screen reader only” text. Still, you should use caution with visually hidden "screen reader only" text (e.g. the "visually-hidden" CSS class) and try to place it after the visible text of a button, form label, link or any other control to ensure compatibility with voice control software. A voice control user must be able to speak the accessible name of an object to interact with it. This is difficult if the accessible name is different from what the user can see.
Words or passages in another language SC 3.1.2
Sometimes content will include words or passages in a different language. Wrap them with an appropriate html element and assign the proper value to the lang attribute of the element. Common expressions that happen to be borrowed from a different language (déjà vu) are exempt. https://www.w3.org/WAI/WCAG21/Techniques/html/H58.html
Example:
<p>
All free men, wherever they may live, are citizens of Berlin, and, therefore,
as a free man, I take pride in the words
<span lang="de">"Ich bin ein Berliner."</span> -John F. Kennedy
</p>
Change of context on focus SC 3.2.1
Developers must not employ Javascript to change the context of the page in response to an element receiving or losing focus. Examples of failures:
- When a certain element receives focus, responding to that event by sending focus elsewhere.
- When a certain element receives focus, changing page content to a degree that it changes the meaning of the page.
- Revealing a submenu on hover is ok. It is not a significant change that changes the meaning of the page.
- But changing page content; loading a "Contact Us" form in place of "Our History" text due to the user tabbing through a main navigation menu (not activating any of the menu links) is a significant change that changes the meaning of the page.
Change of context on input SC 3.2.2
Elements that accept user input must not be programmed in a way that causes a change of context where the user is not sufficiently warned beforehand. A classic violation of this rule is scripting the <select> form element to behave like a navigation control, where choosing an item from the list causes the user to navigate to a completely different page.
Other changes of context include:
- Changes of the user agent (actions that launch a different app)
- Changes to the viewport (forced scrolling of the page or opening another window)
- Changes of focus
- Changes of content that changes the meaning of the page.
Consistent Identification of Functionality SC 3.2.4
Designers and developers must use identical naming strategies for similar functionality throughout the site. Example: A Print button should not be labelled "Print Page" in some places and "Output Page" in other places when they do the same thing. This rule extends to the accessible names given to elements as well.
Error notification SC 3.3.1
Errors must be communicated in text. Errors may also be communicated visually with icons and color changes. Ensure that the error messages are clear enough to allow the user to fix the issue.
Labels and instructions SC 3.3.2
All user inputs must have labels. Instructions are also desirable if there any chance the purpose of the input might be misinterpreted or a certain format needs to be entered. Instructions are important for preventing errors prior to validation. When a user needs to enter data, it is a better experience to get it right the first time. Associate instructions with their inputs by using the aria-describedby attribute on the input element.
Error messages must help the user resolve the error SC 3.3.3
It is up to the designer and developer to write helpful error messages when there are known ways that users can enter the wrong thing.
UI elements and the values they store must be able to be understood by the browser SC 4.1.2
Stick to semantic, valid HTML whenever possible. Using JavaScript and ARIA to make elements behave like something they are not requires testing to ensure elements work as intended and are correctly understood by the browser and assistive technologies.