Accessible Documents in Tumult Hype

accessibility

#1

If you’ve created accessible content in Hype following these guidelines or those posted on the WebAim.org site, please get in touch.

We are interested in both seeing how you approach building accessible content and improving our support. For more information about how to create accessible content with Hype, please see:

For a great walkthrough of some design considerations for building accessible webpages, please see this presentation at Funka’s accessibility conference: https://www.filamentgroup.com/lab/accessibility-funka.html

For additional information about WCAG (Web Content Accessibility Guidelines), please check out:

The checklists below are from Wuhcag.com, a site for learning about web accessibility.


Level A (Beginner)

1.1.1 – Non-text Content Provide text alternatives for non-text content

1.2.1 – Audio-only and Video-only (Pre-recorded) Provide an alternative to video-only and audio-only content

1.2.2 – Captions (Pre-recorded) Provide captions for videos with audio

1.2.3 – Audio Description or Media Alternative (Pre-recorded) Video with audio has a second alternative

1.3.1 – Info and Relationships Logical structure

1.3.2 – Meaningful Sequence Present content in a meaningful order

1.3.3 – Sensory Characteristics Use more than one sense for instructions

1.4.1 – Use of Colour Don’t use presentation that relies solely on colour

1.4.2 – Audio Control Don’t play audio automatically

2.1.1 – Keyboard Accessible by keyboard only

2.1.2 – No Keyboard Trap Don’t trap keyboard users

2.2.1 – Timing Adjustable Time limits have user controls

2.2.2 – Pause, Stop, Hide Provide user controls for moving content

2.3.1 – Three Flashes or Below No content flashes more than three times per second

2.4.1 – Bypass Blocks Provide a ‘Skip to Content’ link

2.4.2 – Page Titled Use helpful and clear page titles

2.4.3 – Focus Order Logical order

2.4.4 – Link Purpose (In Context) Every link’s purpose is clear from its context

3.1.1 – Language of Page Page has a language assigned

3.2.1 – On Focus Elements do not change when they receive focus

3.2.2 – On Input Elements do not change when they receive input

3.3.1 – Error Identification Clearly identify input errors

3.3.2 – Labels or Instructions Label elements and give instructions

4.1.1 – Parsing No major code errors

4.1.2 – Name, Role, Value Build all elements for accessibility

WCAG 2.0 checklist Level AA (Intermediate)

1.2.4 – Captions (Live) Live videos have captions

1.2.5 – Audio Description (Pre-recorded) Users have access to audio description for video content

1.4.3 – Contrast (Minimum) Contrast ratio between text and background is at least 4.5:1

1.4.4 – Resize Text Text can be resized to 200% without loss of content or function

1.4.5 – Images of Text Don’t use images of text

2.4.5 – Multiple Ways Offer several ways to find pages

2.4.6 – Headings and Labels Use clear headings and labels

2.4.7 – Focus Visible Ensure keyboard focus is visible and clear

3.1.2 – Language of Parts Tell users when the language on a page changes

3.2.3 – Consistent Navigation Use menus consistently

3.2.4 – Consistent Identification Use icons and buttons consistently

3.3.3 – Error Suggestion Suggest fixes when users make errors

3.3.4- Error Prevention (Legal, Financial, Data) Reduce the risk of input errors for sensitive data



#2

Being able to set a WebVTT file for video would be an easy way to improve accessibility.

You could also add a WCAG checker to Hype. A basic way to do that would be contrast warnings on text. If the text is too small, when compared to the background color, Hype could give an error.

Realistically, Hype is about animation. That’s not something that easily translates to a screen reader. You could have an overall project setting that uses Aria tags to ignore the Hype project.

https://www.w3.org/TR/wai-aria/states_and_properties#aria-hidden