Digital Accessibility Standards Rubric

The Department of Justice (DOJ) published a new rule on digital accessibility under Title II of the Americans with Disabilities Act (ADA) on April 24, 2024. This rule requires higher education web content, including Canvas course content, to be accessible by April 26, 2027.

To support this initiative, we have created a Digital Accessibility Standards Rubric based on the WCAG 2 Level A and Level AA guidelines. This rubric helps faculty and staff review webpages, Canvas courses, documents, forms, and educational tools used by students, so you can identify and address accessibility issues before the deadline. A downloadable version and a procurement version are included to help you document your progress or evaluate new tech products.

Training sessions are available each term in the CTL Events Calendar, and our Digital Accessibility guides walk you through many of the key skills. We also recommend using WCAG in Plain English to further understand the expectations of creating accessible digital content.

Content Writing Standards

The content writing standards section is geared towards authors, content editors, and web developers. These statements focus on how text is written, labeled, and structured.

1.01 Meaningful Titles, Headings, and Labels

Page titles, headings, and labels clearly communicate the topic or purpose, helping users understand and navigate the content. Ensure browser tabs, course elements, and document windows display a meaningful title, so users know what the content is about before reading the information.

1.01 Aligns to WCAG: 1.3.1 - Info and Relationships and 2.4.2 - Page Titled

1.01 Examples:

Instead of naming a Canvas module Week 2, name it Week 2: Photosynthesis so students know what the content covers before clicking.
When creating a webpage, use a page title like Scholarship Application Instructions instead of something generic like Information or Home.
Make sure any platforms you’re evaluating allow admins to customize headings, titles, and labels. For example, the system should let you rename a default Item 1 to Orientation and Welcome Materials.

1.02 Formatted Headings

Formatted headings are used to structure sections and subsections of text.

1.02 Aligns to WCAG: 2.4.6 - Headings and Labels

1.02 Examples:

In Canvas, use the option for Heading 2 to style a content section named Assignment Instructions instead of just bolding or enlarging the text.
When editing a webpage, enter titles in the content editor or use HTML heading tags to organize sections named Eligibility Requirements and Application Deadlines instead of just using bold paragraph text.
Confirm the product allows content creators to apply proper heading levels that assistive technologies can recognize, not just change text size for appearance.

1.03 Logical Reading Order

Reading order makes sense. The order of text and images matches how a person would naturally read the page.

1.03 Aligns to WCAG: 1.3.2 - Meaningful Sequence

1.03 Examples:

When designing PowerPoint slides, arrange elements from top to bottom and left to right, so students read content in a natural order without confusion.
On a webpage, make sure the content starts with a heading, followed by descriptive text and any related images or buttons. Ensure screen readers can read the correct order of any side-by-side layouts or other layout designs.
Ensure the platform allows designers to control or confirm the reading order of content elements, especially when exporting to formats like PDF or using drag-and-drop builders.

1.04 Images of Text

Text is written to share information rather than using images of text.

1.04 Aligns to WCAG: 1.4.5 - Images of Text

1.04 Examples:

Instead of uploading a screenshot of an assignment prompt, type the instructions directly into the Canvas text editor so students can select, zoom, or have it read aloud.
When adding a quote to a webpage, type the quote using the text editor and style as a quote so the HTML can be read properly by screen readers.
Check that the platform displays text using real text elements rather than embedding it in images. If logos or graphics include important text, confirm that information is also available in plain text or alt text.

1.05 Referential Statements

Referential statements like “see below” are not used on their own, instead context is provided for text to make sense regardless of location.

1.05 Aligns to WCAG: 1.3.1 - Info and Relationships

1.05 Examples:

Instead of writing “See below for the reading,” write “See the Assigned Reading section at the end of this page.”
Avoid writing “Click the link above.” Instead, write “Click the Submit Your Request link in the Forms section.”
Check that the product uses clear references like section names or labels in its instructions rather than phrases like “click here” or “see below,” which can confuse screen reader users.

1.06 Graphical Symbols

The intention of graphical symbols, like +/- are clear, without relying on color, image, or position alone to help identify icons.

1.06 Aligns to WCAG: 1.3.1 - Info and Relationships and 1.3.3 - Sensory Characteristics

1.06 Examples:

Instead of writing “Click the + to add a comment,” write “Click the Add Comment button marked with a plus sign under the announcement.”
Instead of writing “Click the + to expand,” write “Click the Expand All button marked with a plus symbol to view all FAQs.”
Confirm the platform provides labels or tooltips for icons, and does not rely solely on symbols like arrows, checkmarks, or color changes to communicate actions or status.

1.07 Descriptive Hyperlinks

Hyperlinks use meaningful, descriptive words, instead of generic text like website, read more, or click here.

1.07 Aligns to WCAG: 2.4.4 - Link Purpose (In Context)

1.07 Examples:

Instead of linking “Click here to view the lecture slides,” add the link to the words View Week 3 Lecture Slides.
On a webpage, instead of linking the words “Read more,” write “Learn more about scholarship eligibility requirements” and link the words scholarship eligibility requirements.
Confirm that the platform supports and encourages descriptive link text, such as “Submit Your Timesheet” instead of vague links like “Click here” or text that only makes sense visually.

1.08 Labels and Instructions

Instructions indicate the required format and what kind of info is needed.

1.08 Aligns to WCAG: 3.3.2 - Labels or Instructions

1.08 Examples:

For a Canvas Assignment with file restrictions, instead of just writing Upload your file, write Upload your file as a PDF or DOCX format. Other file types won’t be accepted.
When creating a form in Adobe Sign, use the default value field to show a format example, like 123-456-7890, inside the phone number box.
Or add a tooltip or field label that says Phone Number (format: 123-456-7890) so users know exactly how to enter the information.
Confirm that the platform allows field-specific instructions, like Enter your student ID without dashes, to appear clearly next to each input.

1.09 Use of Tables

Tables are used only to organize data, not for layout or spacing. Each table includes headers that explain each row or column, and PDF tables are correctly tagged so screen readers can interpret their structure.

1.09 Aligns to WCAG: 1.3.1 - Info and Relationships

1.09 Examples:

In Canvas, use the table tool to type data and include a header row so screen readers can identify each column.
Don’t use a table just to align text or other content in columns.
When using Microsoft Word to create a form intended for PDF distribution, use the Table Design tab to set header rows and enable “Repeat Header Rows”.
- Export to PDF using File > Save As instead of the Print to PDF option.
- Check the “Document structure tags for accessibility” option to ensure screen readers can follow the table layout.
Ensure the platform uses properly tagged data tables (not layout tables) and retains row and column headers when exporting to PDF.
Ask vendors how they support screen reader compatibility for tables in their documents and reports.

1.10 Attached or Linked Content

Any university process or curriculum-required attached documents, linked content, or ed tech tools all pass accessibility expectations.

1.10 Aligns to WCAG: All WCAG

1.10 Examples:

Apply the same standards you use for your own content when selecting other people's content.
Before posting a PDF or linking to an article, check that the document has readable text instead of just a scan.
Ensure documents use heading styles and include alt text for images.
Make sure any linked videos have captions.
Ask vendors whether their platform links to external tools or third-party content, and how they verify those linked resources meet accessibility standards. Accessibility should extend beyond the core platform.

Visual Design Standards

The visual design standards section is intended for authors, designers, and content editors. These statements focus on layout, contrast, icons, and visual clarity.

2.11 Consistent Navigation

Page layout, navigation, and menus stay consistent across the course, site, or app to support predictable navigation.

2.11 Aligns to WCAG: 3.2.3 - Consistent Navigation

2.11 Examples:

Set up each weekly module in the same order. Start with an Overview, then Readings, then Assignments, so students know what to expect and where to find things every week.
Use the same top or side menu layout and section titles across all department pages. For example, if the Contact Us link appears at the bottom right of one page, it should be in the same place on all others.
Confirm that the platform uses a consistent layout for menus, buttons, and navigation across all user areas. Ask whether templates or design standards are in place to support predictable user experiences.

2.12 Text Spacing and Layout

Text spacing supports readability by using proper line, paragraph, and section spacing, without relying on blank images or hidden text for layout.

2.12 Aligns to WCAG: 1.4.12 - Text Spacing and 1.3.1 - Info and Relationships

2.12 Examples:

When creating content in Canvas, use the built-in paragraph and heading styles to separate content.
Avoid pressing Enter multiple times or adding blank lines to create space.
Reserve the use of the horizontal divider for separating major sections of information.
When creating content for webpages use proper spacing controls like margins, padding, or line height settings in the web editor.
Do not use white text on a white background,  , multiple <br> tags, or transparent images to add spacing.
Confirm the platform allows users to adjust line spacing and layout using accessible formatting tools—not by inserting blank lines or objects that screen readers can’t accurately interpret.

2.13 Color Contrast

Text color stands out clearly from the background.

Paragraph text color to background color is at least 4.5:1.
Headings and large text contrast with the background at a ratio of at least 3:1 and are sized 18pt or bold 14pt.

2.13 Aligns to WCAG: 1.4.3 - Contrast (Minimum)

2.13 Examples:

When creating content, use dark text on a light background or light text on a dark background to ensure readability.
Avoid placing text directly on top of a photo or gradient unless the background is darkened or a solid color block is added behind the text for contrast.
Confirm the platform meets color contrast requirements and allows users to choose high-contrast themes or templates. Ask if the product flags low-contrast combinations in its accessibility checker.

2.14 When Color Conveys Meaning

Color isn’t the only way information is conveyed. If color is used to label, there’s also a secondary text label.

2.14 Aligns to WCAG: 1.4.1 - Use of Color

2.14 Examples:

Use can use color for emphasis but must also include text cues. For example, if you make all exam titles the color red on your course outline, you must ensure they are also labeled as exams in the name. Exam 1: Intro to Chemistry or Chemistry Exam 1 are acceptable secondary text labels to the use of red font for exams.
On a data dashboard showing enrollment trends, don’t rely only on red or green bars to indicate increases or decreases. Include indicators like arrows or percentage change labels so the data makes sense without color.
Confirm the platform uses both color and a text label to show completion status, warnings, or other feedback rather than using color alone.

2.15 Consistent Icons

Icons are consistently labeled and used to represent repeating functions across pages.

2.15 Aligns to WCAG: 3.2.4 - Consistent Identification

2.15 Examples:

Keep every icon’s purpose consistent across pages.
If you use a target icon to represent learning objectives in one module, use the same target icon with the same meaning in every module. Don’t switch to a star or flag icon for the same purpose elsewhere in the course.
On a department website, if a calendar icon is used to link to event dates, don’t use that same icon elsewhere to link to office hours or meeting notes.
Confirm the platform uses the same icons and labels consistently. For example, if a magnifying glass icon is used for “Search,” it should not also be used for “Zoom” or “Preview” elsewhere in the system.

2.16 Image Alternative Text

If images convey information not explained in the body of text, meaningful alternative text can be added to the image to provide an accurate description.

2.16 Aligns to WCAG: 1.1.1 - Non-Text Content

2.16 Examples:

When adding an image of a food chain diagram to a biology lesson, alt text like “Grasshoppers are eaten by frogs and frogs are eaten by snakes” explains the visual to students using screen readers.
On a webpage about student services, an image shows students meeting with an advisor. The alt text reads: “A student meeting one-on-one with an academic advisor to discuss course planning,” which reinforces the page’s topic without duplicating text already provided.
Confirm the platform allows content creators to add meaningful alt text to all informative images.

2.17 Decorative Images

Products offer a way to mark images as decorative. PDF documents use Artifact tags to hide decorative images.

2.17 Aligns to WCAG: 1.1.1 - Non-Text Content

2.17 Examples:

When adding an image to a Canvas page just for visual appeal, check the box to mark it as decorative so it doesn’t get announced by screen readers.
On a webpage, if a divider graphic is used purely for visual spacing, enter alt="" in the HTML editor or mark the image as decorative if the platform provides that option, so screen readers skip it.
Confirm that the platform allows non-informational images to be marked as decorative, and that PDF exports preserve these settings using proper artifact tagging.

2.18 Image Color Contrast

Non-decorative images that use color to convey important information meet a contrast ratio of at least 3:1, and ideally 4.5:1 or higher.

2.18 Aligns to WCAG: 1.4.3 - Contrast (Minimum) and 1.4.11 - Non-text Contrast

2.18 Examples:

When creating a bar graph in Excel or PowerPoint to upload as an image in Canvas, choose high-contrast colors like dark blue and orange instead of light shades. This ensures the image is readable when inserted into a Canvas page or quiz.
When a colleague sends you an image to post on your department website, check that the colors used in the image have enough contrast.
Confirm the platform provides tools to verify that icons, charts, and interface elements meet the minimum 3:1 contrast ratio. Ask if it supports colorblind-friendly patterns or labels in addition to color.

2.19 Complex Visual and Long Descriptions

Visuals that are too complex for simple alternative text, such as charts and diagrams, link to a longer description.

2.19 Aligns to WCAG: 1.1.1 - Non-Text Content

2.19 Examples:

In a psychology or anatomy course, when adding an image of a brain diagram showing labeled regions and their functions, include short alt text like “Regions of the brain” and then link to a long description that explains each region and its role.
On a webpage showing a campus map with building labels and color-coded zones, include short alt text like “Campus map with labeled buildings” and provide a link to a text-only list of buildings, departments, and accessibility features so the information is available to all users.
Confirm the platform allows content creators to add both short alt text and extended descriptions for charts, maps, or infographics. Ask how those long descriptions are made available to screen reader users.

Multimedia Standards

The multimedia standards section applies to anyone creating or selecting audio and video. These statements focus on required design considerations, transcription, and captioning.

3.20 Audio and Video Transcripts

Audio and videos have accurate transcripts for users to read instead of listening.

3.20 Aligns to WCAG: 1.1.1 - Non-Text Content and 1.2.1 - Audio-only and Video-only (Prerecorded)

3.20 Examples:

When assigning a video interview for a class discussion, the instructor checks that a full transcript is available and includes all spoken content, speaker names, and relevant sounds like [applause] or [patient crying].
When helping produce or post a welcome video from leadership, encourage script writers to include visual descriptions in the narration (e.g., “As I stand in front of our student center…”). Use the platform’s built-in transcript tool and review the transcript for accuracy before publishing to ensure all spoken content is properly captured.
Confirm that the platform supports uploading, linking, or generating transcripts for audio and video files, and that transcripts can be edited for accuracy. Ensure transcripts are accessible using screen readers and keyboard navigation.

3.21 Synced Video Captions

Videos have synced captions that match what’s being said in the video.

3.21 Aligns to WCAG: 1.2.2 - Captions (Prerecorded)

3.21 Examples:

When uploading a recorded lecture that explains the course syllabus, the instructor reviews the auto-generated captions and edits them to fix errors, so the captions match exactly what is said and appear in sync with the speaker.
When adding a student testimonial video to a webpage, ensure captions are time-synced and accurate before publishing. Use the video platform’s caption editor to correct names, technical terms, or punctuation as needed.
Confirm that the platform allows users to review and edit auto-generated captions for accuracy and timing. Ensure captions can be toggled on or off by the viewer.

3.22 Audio Descriptions

An audio description track is required if all visual content is not described in the narration.

3.22 Aligns to WCAG: 1.2.3 - Audio Description or Media Alternative (Prerecorded) and 1.2.5 - Audio Description (Prerecorded)

3.22 Examples:

When recording a video that walks through a slide presentation, the instructor includes verbal descriptions of what’s on each slide—such as reading titles, describing charts, and explaining key visuals—so students who can’t see the screen still understand the content.
When posting a promotional video that shows scenes around campus without narration, staff add a version with an audio description track that explains the scenes [Students walking through the library] or [Apply by July 1].
Confirm the platform supports uploading or linking a separate audio description track and allows users to toggle it on or off. Ask whether detailed text alternatives can be provided when audio descriptions are not feasible.

3.23 Silent Videos

Silent videos include an audio track and transcript describing the action in the video.

3.23 Aligns to WCAG: 1.1.1 - Non-Text Content and 1.2.1 - Audio-only and Video-only (Prerecorded)

3.23 Examples:

When uploading a silent video that shows a patient performing mobility exercises, the instructor adds a narration describing key movements. For example, “The patient lifts their left leg slowly while using the walker for support.”
A short animation on the admissions page shows each step in the application process. Captions are added directly in the video, such as [Step 1: Submit your application] and [Step 2: Upload documents].
Confirm the platform supports uploading or generating audio descriptions or transcripts for silent videos. Ask whether video-only content is flagged or guided to ensure accessibility steps are completed before publishing.

3.24 Audio and Video Controls

Audio and videos don’t auto-play, or they can be stopped. If media starts on its own, there’s a way to stop it quickly. Users can pause or stop moving content, including audio, video, animations or auto-scrolling banners.

3.24 Aligns to WCAG: 1.4.2 - Audio Control and 2.2.2 - Pause, Stop, Hide

3.24 Examples:

When embedding a video from MS Stream or YouTube into a Canvas page, the auto-play setting is turned off so the video doesn’t start automatically. This gives students the choice to play the content when they’re ready.
If a web banner includes a looping animation, a pause button is added to the banner so users can stop the motion if needed, and the control is keyboard accessible and clearly labeled.
Confirm that the platform allows media content to be paused or stopped easily and that auto-play can be disabled. Check that media controls are accessible to both keyboard users and screen readers.

3.25 Video and Animation Flash Threshold

Video and animations do not include elements that flash more than 3 times per second.

3.25 Aligns to WCAG: 2.3.1 - Three Flashes or Below Threshold

3.25 Examples:

A video simulating electrical activity during a lab module includes rapid flashes to represent sparks. The flashing is adjusted to stay under three times per second, and a note is added above the video: No strobe effects; safe for users with light sensitivity.
When planning an animation for webpage, avoid using rapidly flashing elements like blinking or strobe effects. Instead, choose slow fade or gentle movements
Confirm the platform prevents or limits flashing content. Ask whether warnings are provided for any preloaded media with visual effects and if alternative, static versions can be offered to users who need them.

3.26 Accurate Response Indicators

Learning applications auditorily and visually indicate correct and incorrect responses.

3.26 Aligns to WCAG: 1.1.1 - Non-Text Content

3.26 Examples:

When creating interactive lessons, add text and audio cues to tell students they got the correct or incorrect answer.
Confirm the platform provides both visual and audio response indicators, and that all feedback is accessible to screen readers and can be understood without relying on color or sound alone.

Assistive Features Standards

The assistive features section is relevant to content creators and individuals selecting tech for student use. These statements address compatibility with assistive technology.

4.27 Resize Text Capability

Technology options exist for text to be resized up to 200%.

4.27 Aligns to WCAG: 1.4.4 - Resize Text

4.27 Examples:

After publishing course content, zoom to 200% in your browser to confirm that text remains readable and content doesn’t break or require horizontal scrolling.
Review webpages at 200% zoom to ensure text scales properly, menus remain functional, and content does not overlap or disappear.
Confirm the platform supports text resizing up to 200% without layout issues, and that users can zoom using browser settings without losing content or navigation access.

4.28 Screen Reader Accuracy and Change Alerts

Screen readers accurately announce content in a logical order, and assistive technology alerts users to changes on the screen without disrupting their navigation.

4.28 Aligns to WCAG: 4.1.2 - Name, Role, Value and 4.1.3 - Status Messages

4.28 Examples:

Press Tab to move through buttons, links, and form fields. If the order feels confusing or jumps around, it likely won’t make sense to screen reader users either.
As you tab, check that each item you land on has a visible outline or highlight. If you can’t see where you are, neither can someone navigating without a mouse.
Submitting forms should display a message nearby confirming what happened, and the page shouldn’t jump, reload, or move your cursor unexpectedly.
Hover over elements to check if labels are meaningful.
Ask the vendor representative to explain how their product is tested to work with screen readers.

4.29 Language of Page and Content Text

Content sets the correct language, using HTML language codes, so screen readers can pronounce both the main page and any foreign language words accurately.

4.29 Aligns to WCAG: 3.1.1 - Language of Page and 3.1.2 - Language of Parts

4.29 Examples:

When including a quote in another language, such as French, use the HTML editor to wrap the text in your text goes here so screen readers pronounce it correctly.
When creating a Spanish-language page on an English website, set the page language to Spanish (lang="es") in the page settings or HTML. This ensures screen readers pronounce the entire page correctly for Spanish-speaking users.
Confirm the platform allows authors to define a default language for each page or document and tag individual sections in other languages so screen readers can switch pronunciation as needed.

4.30 Live Video Captions

Live videos have captions that show what’s being said in real time.

4.30 Aligns to WCAG: 1.2.4 - Captions (Live)

4.30 Examples:

A guest speaker presents to students in Microsoft Teams. Students are instructed to turn on live captions in their settings if they want to follow the spoken content as text.
A YouTube livestream is embedded on the university website. Captions were enabled in the stream settings so viewers can choose to turn them on during playback.
Confirm the platform allows live captioning to be enabled in advance by hosts or organizers, and that viewers can toggle captions on or off during the session.

4.31 Consistent Label Names

Buttons, fields, and controls are labeled clearly so screen readers can announce them accurately. Visible labels match what is announced. For example, if a button text states, “Submit,” a screen reader announces the word submit to the user.

4.31 Aligns to WCAG: 2.5.3 - Label in Name and 4.1.2 - Name, Role, Value

4.31 Examples:

If a button text says Submit, a screen reader should announce the word submit, not button, upload, or other mismatched word.
If hovering shows a different word, there may be a mismatch.
Edit Adobe Sign elements to ensure consistent names and labels when creating forms.
Use the Tab key to reach a button or form field. If you can’t tell what it does from the text alone, it’s likely inaccessible to screen readers too.
Ask the vendor representative to explain how interactive elements are handled by the platform.

4.32 Single Key Shortcuts

Single-key shortcuts can be turned off, changed, or made to require a modifier key so users don’t trigger them by accident.

4.32 Aligns to WCAG: 2.1.4 - Character Key Shortcuts

4.32 Examples:

If a single key (like E or Z) does something without needing Ctrl or Alt, see if there's a way to turn that off or change it.
Look for shortcut settings that can be adjusted by users to reduce accidental activation, especially for users with mobility or input disabilities.
Ask the vendor representative if the platform allows single-key shortcuts to be disabled, remapped, or modified to require a modifier key.

4.33 Time Limit Controls

Time limits on content like forms, sessions, or activities can be turned off, extended, or adjusted so users aren’t rushed unless extending the time would change the nature of the activity. For example, standardized testing or timed evaluations.

4.33 Aligns to WCAG: 2.2.1 - Timing Adjustable

4.33 Examples:

Instructors moderate assessments in Canvas to extend time limits.
If an online form includes a session timeout for security reasons, display a clear warning before it expires. Offer an alternative way to complete the task, such as a downloadable PDF version of the form or a contact email for assistance.
Confirm the platform allows time limits to be adjusted or turned off for assessments and forms. Ask whether time extensions can be granted individually and whether fixed timers are only used when necessary for the activity’s purpose.

Navigation Standards

The navigation standards section supports course builders, content creators, web designers, and individuals selecting tech for student use. These statements focus on structure, focus order, and predictable behavior.

5.34 Keyboard Capability

All content and controls can be used with a keyboard alone instead of requiring a mouse. For example, using the Tab key to move through links and buttons.

5.34 Aligns to WCAG: 2.1.1 - Keyboard

5.34 Examples:

You can move around the content with the tab key only. Check that dropdown menus and buttons are usable without a mouse.
Drag and drop quiz questions work with the keyboard instead.
Avoid placing important instructions or buttons inside mouse-only hover effects.
Confirm that the platform allows full navigation and use with keyboard only.

5.35 Multiple Ways to Navigate

Users can find content in different ways, such as with menus, search bars, and links.

5.35 Aligns to WCAG: 2.4.5 - Multiple Ways

5.35 Examples:

Instructors can use Modules and offer course menu links to Assignments and Quizzes, offer the course outline in the Syllabus tool, and enable Canvas Smart Search to help students locate information using keywords.
Web content editors can ensure forms, event pages, or policy documents are accessible from the homepage, menus, and cross-linked from related content.
Procurement teams can confirm that platforms offer both structured navigation and a search tool, and allow content creators to provide multiple entry points to important pages.

5.36 Ability to Skip

Users can skip repeated elements. For example, skipping the main menu to get to page content.

5.36 Aligns to WCAG: 2.4.1 - Bypass Blocks

5.36 Examples:

Format Canvas pages using proper headings and avoid placing long menus, banners, or images before the main content so students using keyboard navigation can reach material quickly.
Web content can include a Skip to Main Content link at the top of pages and ensure heading structure allows assistive tech users to bypass repeated navigation.
Confirm the platform includes a built-in skip link or heading-based navigation and that users can bypass repetitive menus using a keyboard or screen reader.

5.37 Focus and Selected Element Behavior

Tabbing and navigation follow a logical order, and no unexpected changes occur when users click or move focus. Pages or actions update only when the user intends.

5.37 Aligns to WCAG: 2.4.3 - Focus Order, 3.2.1 - On Focus, and 3.2.2 - On Input

5.37 Examples:

Tabbing through content follows a logical order and does not trigger an action unless Enter is pressed or the student clicks an element.
Tabbing through content follows the same order it appears visually and elements only open when activated, not just when highlighted.
Confirm the platform maintains logical focus order and does not trigger automatic actions on focus or input without user confirmation.

5.38 No Keyboard Traps

If keyboard focus can be moved to a component, it can also be moved away either by standard exit method or user is advised how to exit.

5.38 Aligns to WCAG: 2.1.2 - No Keyboard Trap

5.38 Examples:

Tabbing through course materials does not get the student stuck.
Dropdowns, overlays, and forms can be closed using standard keys like Esc or Tab, or instructions are provided if a different method is required.
Confirm that the platform avoids keyboard traps and that all interactive components support standard keyboard navigation, especially in modals, widgets, and embedded tools.

5.39 No Obscured Elements

Nothing is hidden when using keyboard navigation and users can see where they are.

5.39 Aligns to WCAG: 2.4.7 - Focus Visible and 2.4.11 - Focus Not Obscured (Minimum)

5.39 Examples:

Instructors adding custom HTML in Canvas should avoid removing focus outlines and should tab through content to confirm that each button or link clearly shows where focus is.
Web content editors can check that when using the Tab key, focus remains visible even inside scrollable panels or pop-ups and doesn’t get hidden behind headers or sidebars.
Confirm that the platform displays consistent, visible focus indicators on all interactive elements and that nothing is cut off or obscured when navigating by keyboard.

5.40 Size of Clickable Elements

Buttons are easy to click. They’re big enough and spaced well enough not to miss or mis-click.

5.40 Aligns to WCAG: 2.5.8 - Target Size (Minimum)

5.40 Examples:

Custom buttons or links must have at least a 1/4-inch target and enough space around them to avoid mis-clicks.
Verify that links and icons on webpages are easy to tap on mobile devices and not placed too close together.
Confirm the platform has a way to ensure interactive elements meet the 24 by 24 pixel minimum size and can be activated easily on touchscreens without requiring zoom or precision tapping.

5.41 Visual Feedback for Buttons

Buttons provide clear visual feedback when clicked or activated. Avoid image-only buttons that don’t show a state change.

5.41 Aligns to WCAG: 3.2.2 - On Input

5.41 Examples:

At UIW, images used as buttons in Canvas have a visible state change added to them automatically.
For webpages, test buttons by clicking or tabbing to them and checking for a clear visual response like a color change or shadow to show the button has been activated.
Confirm the platform has a way to manage all buttons and interactive elements will show a visible state change when used and that image-only buttons include hover or focus feedback.

5.42 Hover and Focus Behaviors

When pointer hover or keyboard focus triggers visibility of additional content, there is a way to dismiss the action, the pointer can be moved without hiding the content, and the content remains visible until dismissed by the user.

5.42 Aligns to WCAG: 1.4.13 - Content on Hover or Focus and 2.4.7 - Focus Visible

5.42 Examples:

When using interactive tools like flashcards, ensure the content stays visible when using the keyboard, can be dismissed with Esc or a close button, and doesn’t disappear when moving the mouse or focus.
Avoid relying only on hover to reveal important information and confirm that tooltips or pop-ups remain visible until dismissed by the user.
Confirm the platform supports dismissible, keyboard-accessible hover or focus content that stays visible long enough for users to read and interact with.

5.43 Error Prevention

For web pages that cause legal commitments or financial transactions for the user, submissions are either reversible, reviewable, or able to be cancelled before submission.

5.43 Aligns to WCAG: 3.3.4 - Error Prevention (Legal, Financial, Data)

5.43 Examples:

Forms that involve legal or financial commitments must allow users review their input, go back, or cancel before the submission is final.
Consider a message like Are you sure you want to submit? before processing important actions.
Confirm the platform includes safeguards for legally or financially significant actions, such as review steps, cancel buttons, or confirmation dialogs before final submission.

5.44 Consistent Help and Support Location

Help or support links appear in the same place on each page, so users always know where to find assistance.

5.44 Aligns to WCAG: 3.2.6 - Consistent Help

5.44 Examples:

The Canvas Help button is always located in the Global Navigation Menu.
Place additional help or support links in the same location on each page and use consistent wording like Help or Get Support.
Standardize help links across all webpages, ensuring users always find assistance in the header, footer, or a fixed sidebar—not just on select pages.
Confirm the platform allows globally placed help links and supports persistent or sticky help features that appear consistently across all user screens.

Development Standards

The development standards section is geared toward IT security, form creators, web developers, and individuals selecting tech for student use. These statements cover technical interaction, responsiveness, and input requirements.

6.45 Responsive in Portrait and Landscape Orientation

Apps or content display in portrait or landscape orientation. Content is responsive and wraps within the screen size instead of requiring the user to scroll to the right.

6.45 Aligns to WCAG: 1.3.4 - Orientation and 1.4.10 - Reflow

6.45 Examples:

Avoid uploading materials like landscape-oriented PDFs that require sideways scrolling on mobile devices, and ensure videos or pages display properly without needing to rotate the screen.
Test webpages by rotating your device to confirm that text and images reflow correctly and content remains readable in both portrait and landscape views.
Confirm the platform supports responsive layout across orientations and does not require users to rotate their device to view or interact with content.

6.46 No Motion to Activate

Users don’t need to move, shake, or tilt their device to use content.

6.46 Aligns to WCAG: 2.5.4 - Motion Actuation

6.46 Examples:

Instructors using apps or simulations should ensure students can complete activities without shaking, tilting, or rotating their devices, and that on-screen buttons are available as an alternative.
Web content editors should avoid embedding features that rely on device motion, such as shake-to-refresh or tilt-to-navigate, unless an accessible alternative is provided.
Confirm the platform does not require motion-based input and that any motion features include an alternative method using standard touch or keyboard controls.

6.47 Simple Gestures and No Drag Requirements

All actions can be completed with a simple tap, click, or keypress. Dragging or complex gestures are not required unless an easier option is provided.

6.47 Aligns to WCAG: 2.5.1 - Pointer Gestures and 2.5.7 - Dragging Movements

6.47 Examples:

Digital activities using drag-and-drop matching or sorting tasks, must provide an alternative option to use arrow keys or tap-to-select.
Simulations or interactive media must not require pinch, swipe, or multi-finger gestures.
Confirm the platform offers a way to manage interactions to be completed with a single tap, click, or keyboard command, and that accessible alternatives are available for any gesture-based tasks.

6.48 Pointer Action Requirements

Single pointer actions meet at least one of these requirements

Not executed by the down-event.
Completes on the up-event and can be aborted.
The up-event reverses the preceding down-event.
Completion on the down-event is essential.

6.48 Aligns to WCAG: 2.5.2 - Pointer Cancellation

6.48 Examples:

Use tools or activities where buttons and links activate on release (up-event), not immediately on press, especially for actions like submitting work or deleting items.
Avoid interactive elements that trigger permanent changes on the down-click or touch and instead ensure users can cancel or undo actions before they complete.
Confirm that platform actions are triggered on the up-event or offer a confirmation step, especially for irreversible actions like deleting or submitting.

6.49 Form Field Instructions and Notifications

Form fields are easily understood:

Users can tell what information they’re supposed to enter because form fields are labeled clearly.
Users are told what is wrong when there's an error and how to fix it.
Form fields notify the user of errors when entries are incorrectly formatted.

6.49 Aligns to WCAG: 1.3.5 - Identify Input Purpose, 3.3.1 - Error Identification, 3.3.2 - Labels or Instructions, and 3.3.3 - Error Suggestion

6.49 Examples:

Build quizzes and forms with clearly labeled input fields.
Include format hints like Enter your email (name@example.com) instead of vague messages like Invalid input.
Customize default field names in Adobe Sign forms to be descriptive. For example, Phone Number instead of Box 1.
Ensure error messages explain what went wrong and how to fix it.
Confirm the platform uses clear, programmatic labels for form fields, provides both visual and text-based error feedback, and supports screen reader announcements for input errors and suggestions.

6.50 Simple Access Processes

Users don’t have to repeatedly enter info to avoid being signed out.
If they already entered information once, they won’t be asked again.
Users aren't required to solve puzzles, remember passwords, or complete other mental tasks to log in, unless there's an easier option offered.

6.50 Aligns to WCAG: 3.3.7 - Redundant Entry and 3.3.8 - Accessible Authentication (Minimum)

6.50 Examples:

Use platforms that support single sign-on (SSO) and password managers, so users don’t have to remember or re-enter credentials repeatedly.
Web content editors and form builders should avoid requiring users to retype the same information, like name or email, in multiple steps of a process.
Confirm the platform supports accessible login options that don’t rely solely on memory or visual tasks, and that repeated entry of information is avoided within the same session.