Theravue Style Guide

Overview

Technical accessibility requirements come from Web Content Accessibility Guidelines (WCAG) 2.1, accessibility audits, OR suggestions from our users with specific accessibility needs.

Listed below are general accessibility guidelines. For accessibility related to specific elements, see their Elements section.

Contrast

In order to meet accessibility standards, text on Skillsetter must meet a certain threshold of foreground-background contrast ratio.

We are aiming for a contrast ratio of at least 4.5:1 for most text.

"WCAG 2.0 level AA requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text. WCAG 2.1 requires a contrast ratio of at least 3:1 for graphics and user interface components (such as form input borders). WCAG Level AAA requires a contrast ratio of at least 7:1 for normal text and 4.5:1 for large text." https://webaim.org/resources/contrastchecker/

Contrast can be tested here, or using WAVE accessibility tools, etc.

Audio Descriptions

Text descriptions of audio should be provided whenever possible-- preferably in both caption and transcript form.

Transcripts should be toggled by a button right after the media it is related to.

Keyboard Navigation

Focus Visibility

Focus should always be a blue glow around all visible elements. This should be automatically applied.

Focus Order

When tabbing through the site on keyboard view, the focus should never "skip" elements or go out of order.

Hidden Elements

Hidden elements, when focused on, should always become visible. To hide elements from screen readers AND keyboard users, use display: none; or class="d-none".

Aria-hidden

Hides elements from screen readers.

Example:

<i class='fa fa-check' aria-hidden='true'></i>
Your audio and video seem to be working.

Here, the check icon is a quick supplementary reference for sighted users to tell them everything is working properly. The check icon is not needed for screen readers, since the text reads the same information.

Screen Reader Only Text

Used when the user would not be able to understand the meaning of an element (for example, an icon) without text, but no text is required for sighted users. sr-only elements are invisible and only appear for screen readers.

Example:

<span class="sr-only">

Delete this <%= CaseStudy.model_name.human.downcase %>

</span>
<i class="fa fa-trash text-right" aria-hidden="true"></i>

Cameratag

Begin Practice Case & Watch stimulus + response Button

Alternate links in the form of buttons must provided so that all screen readers can easily find these buttons.

Format:

<button class="sr-only both-videos-btn" aria-label="Watch stimulus and response"></button>
<a class="widget-btn clearfix both-videos-btn">

... Visual button content for "Watch Stimulus + Response"

</a> <button class="sr-only widget-btn start-practice-case" aria-label="Begin <%= CaseStudy.model_name.human %>"></button>
<a class='widget-btn start-practice-case'>

... Visual button content for "Begin Practice Case"

</a>

Skip Controls: "Done", "Skip to Response", "Back to Stimulus"

These controls appear when the user moves the mouse into the response widget after playback starts. They disappear after a few seconds if the user moves away.

If the d-none class is used, these controls are hidden visually and from screen readers. They are completely inaccessible.

If the sr-only class is used, controls are meant to be hidden visually, but still accessible-- for example, when mouse users would be able to hover.

Jaws Link Incompatibility: See Known Issues

Zoomed Styling

Viewport to test zoomed in styling should be 1280 x 1024 @ 400% zoom. All functions and text should be available in this view without cutoff or overlap.

Known Issues

There are a number of known issues concerning accessibility.

Cameratag Issues

Cameratag has a number of accessibility issues that we have decided note to work on, as we may switch away from cameratag soon.

JAWS Cameratag Controls

JAWS screenreader has issues around detecting links that encompass a group of elements, including stylized cameratag buttons.

For JAWS, simple play buttons must be provided.

Note that having a separate, screen reader specific button is not typically best practice, but it's the simplest and least risky method of ensuring JAWS users can access the system. If we decide to move from Cameratag, there may be a more streamlined way of doing this.

JAWS controls are currently not available for response creation.

Default Players:

Must be placed above the case-study-player div.

<button class="sr-only sr-play case-study-player-play">Play Video</button>

Response Widget Player:

Must be placed inside the response-show-widget div, above all other inner elements.

<div class="jaws-sr-controls"> <button class="sr-play play-stimulus-first">Play stimulus</button> <button class="sr-play play-response-first">Play response</button> </div>

Testing Issues

JAWS:JAWS can only be tested on a Windows computer with the program installed. However, a license to use this program is quite expensive.

Firefox: Firefox only recently started to support VoiceOver in 2020. Because of this, there may be some issues out of our control on that browser when it comes to screenreaders. For now, screen reader users should be advised to use Chrome.