Accessibility

Last edited 36 seconds ago by System Writer
At Kanopi we aim to meet the requirements for Level AA from the while also looking ahead to what standards will be included in the next version.
While the official document is comprehensive and well documented, the is a lot easier to parse, search, and filter, and will be referenced here in this document. It’s also .

Principle 1 -

Provide text alternatives for all content that relies on visual context
Menu buttons, close buttons, shopping cart icons, charts, etc.
All image elements must have the alt attribute, no exceptions
<img src="#" alt /> and <img src="#" alt="" /> are acceptable.
Videos and audio files require captions or transcripts in order to present a text alternative for that media.
Auto captioning is acceptable.
Use semantic HTML wherever possible.
Use HTML5 elements and landmarks
Add ARIA where relationships are unclear
Organize pages with headings
DOM order should match the visual order
Exceptions can be made, but only if the result is not confusing visually or audibly.
Do not indicate purpose solely with color.
Links must have another visual indicator (icons, underlines, backgrounds, design elements, placement)
If colors were removed, information should not be lost.
Text requires a contrast ratio of 4.5:1
Text larger than 24px, or 19-23px that is bold, only need to meet 3:1
Graphic elements (such as icons, checkboxes, etc) need to meet 3:1
Test your work at zoom 200%. You must still be able to read the content and use the site.
Do not disable zooming for any reason.
Use rem or % for font sizes to ensure they obey browser settings.
Do not use images of text.
If images of text are required, that content must also be provided in an alternative text format.
Logos are exempt from this rule.
Do not justify text.
Though this is a Level AAA item, it is a practice Kanopi follows.
Line spacing must be a minimum of 1.5 for body text.
Though this is a Level AAA item, it is a practice Kanopi follows.
Build responsively. Check your work at all viewports from 320px and up.
Line-height must use no measurements, or it must use rems (by default line-height uses rem).
User must be able to change site line-heights and still be able to view and use all content.

Principle 2 -

All site functionality must be operable through a keyboard interface.
Menu buttons, close buttons, links, sliders, tabs, accordions, etc.
Do not trap a user via keyboard.
Videos, audio, gifs, moving, or auto scrolling content must include Pause, Stop, Hide controls.
2.2.2 Pause, Stop, Hide - Level A
Do not design content in a way that is known to cause seizures or physical reactions.
Includes videos and gifs.
Add a “skip to” link that bypasses the header and goes straight to the main content.
Webpages must have titles that accurately describe the purpose of the page.
Focus order should be sequential and logical.
Exceptions can be made, but only if the result is not confusing.
All links must have textual content that indicates where the link goes.
“Read More” / “Learn More” are not appropriate link names on their own.
Screen reader text can be added to most links to provide article titles, or other context about the destination.
Images used as links must use their alt text to identify the destination of the link.
Do not misuse headings to achieve a design.
Headings are meant to describe a topic or a purpose, not as an application of style.
The keyboard focus must be visible.
Focus status should not be subtle changes. The outline property is well known and easily identified.
Do not disable the default focus styles if you do not intend to replace them.
Use section headings appropriately.
Headings should be used .
Though this is a Level AAA item, it is a practice Kanopi follows.
Ensure target sizes on mobile are easy to tap.
Target size is at least 44px by 44px.
Does not apply to inline links and typically does not apply to navigation lists.
Though this is a Level AAA item, it is a practice Kanopi follows.

Principle 3 -

All pages must have a language code.
Sections of content that is presented in another language must also identify the language used.
Form inputs must include textual error messages.
Form inputs must include labels or instructions.

Principle 4 -

Do not leave broken tags or stray tags.
Elements must be nested according to their specifications.
Do not put a <div> inside a <p> or an <a> inside an <a>
If you are unfamiliar with valid HTML, please reach out to your manager for training.
Do not duplicate IDs within a page.
IDs must be unique. Use a class instead if the element will be duplicated on a page.
Use a keyboard to operate all components of the site
Also check focus order and focus states
Zoom to 200%
Repeat keyboard testing
Ensure all content is still readable and usable
Automated Scans
- Required
- Recommended
Check uncertain color combinations with a
If text appears overtop of an image, sample the color closest in hue to the color of the text and run it through the checker. If it fails, then you need to change the color of the text, or add an overlay to the image, or both.
Manual review
Images do not contain text
Images have appropriate alt text
Headings are used sequentially
Hover states exist
Site is responsive and reflows properly from 320px and up
Screen Reader Testing
Alternatively, your developer tools will give you access to the accessibility tree which will give you an indication of what content is being passed through to assistive technology.
Ally Teaching & Learning is a monthly session Kanopians can attend to talk through accessibility concepts and guidelines. You can find all of , or search for the term “”. Some intranet documents include session videos.
There are 4 specific aspects of the WCAG guidelines and they are defined by the acronym “POUR”. This is a general summary of what you can find in each area.

Everything in the 1 point rule set has to do with an individual’s ability to perceive the content. It’s broken out into four areas.
1.1 - Text Alternatives.
Could someone perceive this content if they were unable to see it?
Can a machine without eyes understand this content? That’s how assistive technologies work.
1.2 - Time-based Media.
Can anyone, regardless of ability or disability, consume your media?
What if they can only see?
What if they can only hear?
What if they can do neither and depend on assistive technology to interpret content in another manner such as Braille?
What if they have motor difficulties that prevent them from using the interface quickly?
1.3 Adaptable
Do users need to meet specific requirements in order to perceive your page and its content?
Can content be perceived and understood with changes to screen size?
Does content make sense in the order it’s presented? Is its purpose clear programatically?
1.4 Distinguishable
Is the presentation clear and understandable?
Is content easily identified without needing context clues like color?
Does the design interfere with the ability to consume content?
Does anything interfere with the user’s ability to use the whole page? (For example, an autoplay video or audio file would be considered an interference).

Everything in the 2 point rule set has to do with an individual’s ability to operate the page. It’s broken out into five areas.
2.1 - Keyboard Accessible
Can a user operate this page with just a keyboard?
Can all of the links and interactive elements be reached and activated via keyboard?
This is critical because many assistive technologies operate with keyboard interactions.
2.2 - Enough Time
Does the user have the time to operate the page?
Are there timed interactions?
Are there elements that cause interruptions?
Can users control media so that they can consume it at their leisure?
2.3 - Seizures and Physical Reactions
Does this site follow good practices to prevent experiences that are known to cause seizures?
2.4 - Navigable
Can the user move around the page in a logical manner?
Is link purpose clear?
Does the content have appropriate headings and labels?
2.5 - Input Modalities
Are target/tap sizes appropriate?
Are target/tap areas too close together?
Does the site rely on swipes or gestures to complete actions and tasks?
Are there alternatives present?

Everything in the 3 point rule set has to do with an individual’s ability to understand the page. It’s broken out into three areas.
3.1 - Readable
Is the language programmatically determined?
Is the content understandable without additional context?
Are there mechanisms for identifying the definitions of abbreviations, industry jargon, idioms, etc?
Is the reading level appropriate?
Is meaning ambiguous without knowing pronunciation?
3.2 - Predictable
Does the page conform to a standard web experience?
Does focusing an element or using an input field produce typical expected behaviour?
Is navigation consistent from page to page?
Are components with the same functionality identified consistently throughout the site?
Are changes of context appropriately managed?
3.3 - Input Assistance
Are input errors easily identified and described to the user?
Are inputs accompanied by labels and, when appropriate, instructions?
Do errors include suggestions for correction?
When collecting legal information, does the user have the ability to correct and review their submissions?

Everything in the 4 point rule set has to do with a device’s ability to understand the page. It’s broken out into one area.
4.1 - Compatible
Is the site compatible with current user agents (browsers, operating systems, assistive technologies)?
Will the site be compatible with future user agents (browsers, operating systems, assistive technologies)?
Do all interface-able components provide enough information that their name and role can be programmatically determined?
When states, properties, or values are changed, is that change made available to user agents?
Are status messages presented to the user without requiring focus?
Images make up a good portion of a website’s design and content, but aren’t accessible to users with low or no vision. How do we make sure they get conveyed to users of assistive technology?

When do they need the “alt” attribute?

Always. This can’t be understated. If you are using <img> or <svg>, then you need the alt attribute. This is to create valid HTML and also passes important info about the image to assistive technologies.
These are all valid html:
<img href="path-to-iamge" alt />
<img href="path-to-iamge" alt="" />
<img href="path-to-iamge" alt="An image of a fluffy orange cat playing with a feathered toy" />
Images that are applied via CSS cannot be given the alt attribute. If your image is important for conveying meaning to a user, you need to find an alternative method for providing that context, perhaps through a caption or hidden screen reader text.

What happens if the image has no alt attribute?

If your image has no alt attribute, then the image name will be presented instead.
img_NCBI-macbook-1x-1-743x475
Kanopi-Icon-Confused-Editor-Trimmed
logo-phr@2x-grey
iStock_Civic-425x275

When does the alt tag need to be filled in?

Only if the image is not classified as decorative.
Decorative images could be:
Background designs like dots, arrows, swoops
Icons that accompany visual labels
Lines, shapes, other items that frame headings or other content
Want to print your doc?
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
CtrlP
) instead.