Upload
others
View
5
Download
0
Embed Size (px)
Citation preview
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
WebSavvy Services Hypothesis Accessibility Audit
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
WebSavvy Services Hypothesis Accessibility Audit
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.
WebSavvy Services Hypothesis Accessibility Audit
6
Success Criterion
Level Evaluation Comments
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
AAA N/A Not an AODA requirement.
1.2.8 Media Alternative
AAA N/A Not an AODA requirement.
1.2.9 Audio-only (Live)
AAA N/A Not an AODA requirement.
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
WebSavvy Services Hypothesis Accessibility Audit
7
Success Criterion
Level Evaluation Comments
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,
WebSavvy Services Hypothesis Accessibility Audit
8
Success Criterion
Level Evaluation Comments
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.
WebSavvy Services Hypothesis Accessibility Audit
9
Success Criterion
Level Evaluation Comments
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.
WebSavvy Services Hypothesis Accessibility Audit
10
Success Criterion
Level Evaluation Comments
1.4.3: Contrast (Minimum)
AA Fail
WebSavvy Services Hypothesis Accessibility Audit
11
Success Criterion
Level Evaluation Comments
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.
WebSavvy Services Hypothesis Accessibility Audit
12
Success Criterion
Level Evaluation Comments
1.4.5: Images of Text
AA Pass No images of text observed.
1.4.6: Contrast (Enhanced)
AAA N/A Not an AODA requirement.
1.4.7: Low or no Background Audio
AAA N/A Not an AODA requirement.
1.4.8: Visual Presentation
AAA N/A Not an AODA requirement.
1.4.9: Images of Text (No Exception)
AAA N/A Not an AODA requirement.
WebSavvy Services Hypothesis Accessibility Audit
13
Principle 2: Operable
Success Criterion
Level Evaluation Comments
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.
WebSavvy Services Hypothesis Accessibility Audit
14
Success Criterion
Level Evaluation Comments
2.1.3 Keyboard (No Exception)
AAA N/A Not an AODA requirement.
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
AAA Not an AODA requirement.
2.2.5: Re-authenticating
AAA Not an AODA requirement.
WebSavvy Services Hypothesis Accessibility Audit
15
Success Criterion
Level Evaluation Comments
2.3.1: Three Flashes or Below Threshold
A
Pass
No flashing content observed.
2.3.2: Three Flashes
AAA Not an AODA requirement.
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.
WebSavvy Services Hypothesis Accessibility Audit
16
Success Criterion
Level Evaluation Comments
E.g. account options and annotation tabs.
2.4.8: Location AAA Not an AODA requirement.
2.4.9: Link Purpose (Link Only)
AAA Not an AODA requirement.
2.4.10: Section Headings
AAA Not an AODA requirement.
Principle 3: Understandable
Success Criterion
Level Evaluation Comments
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
AAA N/A Not an AODA requirement.
WebSavvy Services Hypothesis Accessibility Audit
17
Success Criterion
Level Evaluation Comments
3.1.4: Abbreviations
AAA N/A Not an AODA requirement.
3.1.5: Reading Level
AAA N/A Not an AODA requirement.
3.1.6: Pronunciation
AAA N/A Not an AODA requirement.
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
AAA N/A Not an AODA requirement.
3.3.1: Error Identification
A Pass Error messages are provided.
3.3.2: Labels or Instructions
A Pass Labels and instructions are provided.
WebSavvy Services Hypothesis Accessibility Audit
18
Success Criterion
Level Evaluation Comments
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)
AAA N/A Not an AODA requirement.
Principle 4: Robust
Success Criterion
Level Evaluation Comments
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
WebSavvy Services Hypothesis Accessibility Audit
19
Success Criterion
Level Evaluation Comments
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.
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/).