AODA Accessibility Audit for Hypothesis (embedded within ... · AODA Accessibility Audit for Hypothesis (embedded within Canvas) Prepared by WebSavvy Inclusive Design Research Centre,

AODA Accessibility Audit for Hypothesis

(embedded within Canvas)

Prepared by WebSavvy

Inclusive Design Research Centre, OCAD University

2nd Floor, 205 Richmond St. West, Toronto, ON, M5V 1V3

Tel: (416) 977-6000 #3957 | Fax: (416) 977-9844

Reviewed by: Lisa Liskovoi

May 14, 2018

WebSavvy Services Hypothesis Accessibility Audit

2

Table of Contents

Introduction 3

Content Reviewed 3

Summary of Accessibility Issues 4

WCAG 2.0 Criteria Checklist with Recommendations 5

Principle 1: Perceivable 5

Principle 2: Operable 13

Principle 3: Understandable 16

Principle 4: Robust 18

Technical Information 20


3

Introduction

This accessibility audit reviews Hypothesis functionality for compliance with the Web Content

Accessibility Guidelines (WCAG 2.0) A and AA criteria. The issues described in this report are

organized under WCAG’s four leading principles of accessibility regarding web content. These

principles can be described as:

1. Perceivable - A site must provide text alternatives for non-text content, alternatives for time-

based media, layout alternatives for related or sequential content, and generally make sure all

content is easy to see and hear.

2. Operable - A site must provide keyboard access, enough time to read and use content,

orientation, clear navigation, and organized content. A site must also operate safely without

flashing.

3. Understandable - Content must be readable, consistent, and predictable. Instructions must be

clear and helpful.

4. Robust - Content must be compatible with a variety of user agents and assistive technologies.

Individual criteria successes and failures are described in detail in the WCAG 2.0 Chart included, with

the most important issues explained in the Summary of Accessibility Issues section below. Tools used

for this review, as well as sites useful for implementing the recommended improvements, are listed in

the Technical Information section.

Content Reviewed

This general accessibility review looks at Hypothesis functionality on the following sample page,

embedded within Canvas:

https://hypothesis.instructure.com/courses/19/modules/items/342

https://hypothesis.instructure.com/courses/19/modules/items/342


4

Summary of Accessibility Issues

The conclusion of this review is that the Hypothesis annotation functionality does not conform with

WCAG 2.0 at Level A or Level AA. The accessibility issues identified through this audit are described

in the following sections with the relevant WCAG 2.0 criteria number cited in parentheses.

Recommendations for each issue are located in the Comments of the WCAG 2.0 Criteria Checklist

with Recommendations.

Some accessibility issues include:

• Missing, incorrect or insufficient markup for tabs, show/hide toggles, radio buttons, etc. (1.3.1,

4.1.2)

• Colour alone is used to identify annotated and highlighted content (1.4.1)

• In some case text does not have sufficient contrast with the background (1.4.3)

• Some functionality is not accessible with a keyboard (2.1.1)

• Users are not able to extend of disable time limits before being logged out (2.2.1)

• Keyboard focus is not always visible (2.4.7)

• Validation errors that could interfere with the functioning of assistive technologies are present

in the markup (4.1.1)

WCAG 2.0 Criteria Checklist with Recommendations

The following checklist evaluates each A and AA criterion with a Pass or Fail grade. In cases where a Pass is given but further accessibility

or usability improvements are recommended, a “Minimum Pass” evaluation is given with additional suggestions.

Note: Items with a grey background signify AAA criteria and are not evaluated in this audit. Although they go beyond AA compliance,

developers should attempt to conform with these AAA guidelines wherever possible.

Principle 1: Perceivable

Success Criterion

Level Evaluation Comments

1.1.1: Non-text Content

A Pass

Images have proper text alternatives.

For logos, identify the image as a logo, i.e. “Hypothesis logo” rather than just “Hypothesis”.

1.2.1: Audio-only and Video-only (Prerecorded)

A N/A No audio-only or video-only content observed.

1.2.2: Captions (Prerecorded)

A N/A No audio-visual content observed.

1.2.3: Audio Description or Full Text Alternative

A N/A No audio-visual content observed.


6

Success Criterion


1.2.4: Captions (Live)

AA N/A Not an AODA requirement.

1.2.5: Audio Description

AA N/A Not an AODA requirement.

1.2.6 Sign Language

AAA N/A Not an AODA requirement.

1.2.7 Extended Audio Description


1.2.8 Media Alternative


1.2.9 Audio-only (Live)


1.3.1: Info and Relationships

A Fail

Iframe titles

Add a title attribute to describe the Hypothesis iframe. For more on iframe accessibility, see: https://webaim.org/techniques/frames/.

Show/Hide Content Toggles

Add ARIA to describe the behaviour of show/hide content toggle buttons. To these buttons add the aria-expanded attribute to reflect the state of the content, and aria-controls=”id of collapsible content div”. See “button with data target” example: http://v4-alpha.getbootstrap.com/components/collapse/

E.g. sidebar content toggle

https://webaim.org/techniques/frames/


7

Success Criterion


Radio buttons For custom radio buttons, add ARIA markup to clarify functionality to the user. Add role=”radio” to each option, and an aria-checked attribute that reflects the state of the radio option (true/false). Associate the options with their labels (Newest, Oldest, Location) using the aria-labelledby attribute. Enclose the options in an element and give it a role=”radiogroup”. Add an aria-label to the group, in this case “Sort by” or similar. E.g. radio buttons in sort options.

Pop up elements

Indicate that an element has an interactive pop up element using the aria-haspopup property.

The value of aria-haspop should match the role (menu, listbox, tree, grid or dialog). Add aria-expanded attribute to indicate the state of the content. E.g. posting options for comments.

Tabs

All tabpanel functionality should be marked up with ARIA to describe the purpose and

interaction of the tab elements.

Add role=”tablist” to the tab <ul> and role=”tab” to individual <li>s. On the tab content divs,

add role=”tabpanel” and aria-labeledby=id of its tab. Set aria-selected=”true” for selected tabs,


8

Success Criterion


and aria-hidden=”true” for hidden tab panels. For an example, see: http://accessibility.athena-

ict.com/aria/examples/tabpanel2.shtml

E.g. tabs in the side panel.

Aria-labels

Add aria-labels for inputs and elements that require context that is not evident to non-visual

users.

E.g. the search button is missing a label.

E.g. tags. Without visual information, these links are difficult to identify as tags and may be be

confusing to non-visual users.

http://test.cita.illinois.edu/aria/tabpanel/tabpanel1.php

http://test.cita.illinois.edu/aria/tabpanel/tabpanel1.php


9

Success Criterion


Input errors Programmatically associate errors with the inputs they describe using the aria-describedby attribute. E.g. error messages for login inputs are not read out to AT users because they are not associated with their inputs (screen reader output shown).

1.3.2: Meaningful Sequence

A Pass The reading order of content is meaningful.

1.3.3: Sensory Characteristics

A Pass Instructions do not rely upon visual characteristics or sounds. (e.g. “Click the square icon to…” or “The beep indicates…”)

1.4.1: Use of Color

A Fail

Colour alone is used to identify content that is annotated. Consider providing an additional indicator, such as an outline, underline or bolded text. Alternatively, allow users to control the presentation of annotation, including providing different colour options, outlines, etc.

1.4.2: Audio Control

A N/A Did not observe any audio that plays automaticlly.


10

Success Criterion


1.4.3: Contrast (Minimum)

AA Fail


11

Success Criterion


1.4.4: Resize text

AA Minimum Pass

Users should be able to increase the size of text to 200% without loss of content or functionality and without requiring horizontal scrolling.

Content resizes well, however when increased to 200%, it obscures the article content as well as the show/hide toggle. This is likely to make the sidebar difficult to interact with for users who require magnification.


12

Success Criterion


1.4.5: Images of Text

AA Pass No images of text observed.

1.4.6: Contrast (Enhanced)


1.4.7: Low or no Background Audio


1.4.8: Visual Presentation


1.4.9: Images of Text (No Exception)



13

Principle 2: Operable

Success Criterion


2.1.1: Keyboard

A Fail

Some functionality is not accessible with a keyboard. Elements that are not accessible with a keyboard are also not operable with screen readers.

E.g. annotation and highlight buttons are not accessible with a keyboard.

E.g. share and profile options are not accessible with a keyboard.

E.g. the “update” button is not accessible with a keyboard.

E.g. formatting options are not accessible with a keyboard.

E.g. close button in the Share dialog.

2.1.2: No Keyboard Trap

A Pass No keyboard traps observed.


14

Success Criterion


2.1.3 Keyboard (No Exception)


2.2.1: Timing Adjustable

A Fail

For login sessions that expire in less than 20 hours, users require the ability to disable, adjust, or extend the time limit before it is encountered. Before expiry, warn the user and give at least 20 seconds to extend the time limit with a simple action (for example, "press the space bar"), with the user being allowed to extend the time limit at least ten times.

For example, Google Hangouts provides an “Are you still there?” feature to meet this requirement:

2.2.2: Pause, Stop, Hide

A Pass No moving, blinking or scrolling content observed.

2.2.3: No Timing

AAA Not an AODA requirement.

2.2.4: Interruptions


2.2.5: Re-authenticating



15

Success Criterion


2.3.1: Three Flashes or Below Threshold

A

Pass

No flashing content observed.

2.3.2: Three Flashes


2.4.1: Bypass Blocks

A N/A Repeated navigation is minimal.

2.4.2: Page Titled

A N/A Only applicable for web pages.

2.4.3: Focus Order

A

Pass

The focus order of elements is logical.

2.4.4: Link Purpose (In Context)

A Pass Purpose of links is clear.

2.4.5: Multiple Ways

AA N/A Although this criterion applies to entire websites, it is possible to find content through both navigation (annotation categories), and a search function.

2.4.6: Headings and Labels

AA Pass The text of headings and labels is clear and descriptive.

2.4.7: Focus Visible

AA Fail In some cases keyboard focus is not visible.


16

Success Criterion


E.g. account options and annotation tabs.

2.4.8: Location AAA Not an AODA requirement.

2.4.9: Link Purpose (Link Only)


2.4.10: Section Headings


Principle 3: Understandable

Success Criterion


3.1.1: Language of Page

A N/A Only applicable to web pages.

3.1.2: Language of Parts

AA N/A

Only English content observed in plugin. Note: For annotations that are in a language different than the main page language, language should be defined programmatically using the lang attribute in order to ensure proper interpretation by ATs. Consider using language detection or allowing the user to set the language.

3.1.3: Unusual Words



17

Success Criterion


3.1.4: Abbreviations


3.1.5: Reading Level


3.1.6: Pronunciation


3.2.1: On Focus

A Pass No significant changes were observed when an element receives focus.

3.2.2: On Input A Pass No significant changes were observed when an input or control is used.

3.2.3: Consistent Navigation

AA N/A Only applicable to multi-page websites.

3.2.4: Consistent Identification

AA Pass Components that serve the same function are identified consistently.

3.2.5: Change on Request


3.3.1: Error Identification

A Pass Error messages are provided.

3.3.2: Labels or Instructions

A Pass Labels and instructions are provided.


18

Success Criterion


3.3.3: Error Suggestion

AA Pass Error details given. See 1.3.1 for more on associating error messages with the corresponding inputs.

3.3.4: Error Prevention (Legal, Financial, Data)

AA N/A No legal, financial or sensitive data required from users.

3.3.5: Help AAA N/A Not an AODA requirement.

3.3.6: Error Prevention (All)


Principle 4: Robust

Success Criterion


4.1.1: Parsing A Fail

In content implemented using markup languages, elements must have complete start and end

tags, be nested according to their specifications, not contain duplicate attributes, and have

unique IDs, except where the specifications allow these features. These types of errors can

interfere with the operation of assistive technologies.

Parsing Errors

Parsing errors present (93 errors and warnings), including:

• missing required attributes • invalid nesting of elements

In general, ensure valid code by checking pages with the W3C Nu Validator (https://validator.w3.org/nu/). The raw results show all of the source code validity issues, but to Pass this criterion only a sub-set of these issues must be fixed. This subset can be filtered

https://validator.w3.org/nu/


19

Success Criterion


using a special “bookmarklet” found at: http://www.paciellogroup.com/blog/2012/02/wcag-2-0-parsing-error-bookmarklet/

4.1.2: Name, Role, Value

A Fail Add ARIA to hide/show toggles, tabs, pop-up elements, etc.. See 1.3.1 for details.

http://www.paciellogroup.com/blog/2012/02/wcag-2-0-parsing-error-bookmarklet/

http://www.paciellogroup.com/blog/2012/02/wcag-2-0-parsing-error-bookmarklet/

Technical Information

Accessibility of a website is measured against criteria taken from the Web Content Accessibility

Guidelines (WCAG) 2.0 (http://www.w3.org/TR/WCAG20/).

In conducting this review, the following tools were used:

• Firefox 59

• Safari 11

• Chrome 66

• NVDA 2017.1 screen reader

• VoiceOver screen reader

• WebAIM Wave Toolbar

• Nu HTML checker

• TPG Color Contrast Analyzer

These tools were used to generally assess site elements and markup and were not exhaustive in

terms of operating system and browser testing.

In order to address issues identified in this review, we recommend additionally consulting How to Meet

WCAG 2.0: A customizable quick reference to Web Content Accessibility Guidelines 2.0 requirements

(success criteria) and techniques (http://www.w3.org/WAI/WCAG20/quickref/).

http://www.w3.org/TR/WCAG20/

http://www.w3.org/WAI/WCAG20/quickref/

Documents

AODA Accessibility Audit for Hypothesis (embedded within ... · AODA Accessibility Audit for Hypothesis (embedded within Canvas) Prepared by WebSavvy Inclusive Design Research Centre,