Success Criteria Checklist
Perceivable
Definition:
Information and user interface components must be presented in ways that users can perceive. This means people need to be able to see, hear, or feel content if one (or more) of those senses are unavailable.
| Criteria | Success Criterion | Level | Description | Example | Exceptions |
|---|---|---|---|---|---|
| 1.1.1 | 1.1.1 Non-text Content | A | All images and icons used on the CSU website must have alternative text. | A photo of Rhodes Tower has alternative text that screen readers will read as “Rhodes Tower.” | Decorative images don’t require alt text if marked properly. |
| 1.2.1 | 1.2.1 Audio-only and Video-only (Prerecorded) | A | Provide text alternatives to video and audio only content. | A video of an interview posted on YouTube must have closed captioning and a transcript available. | Looping videos that are for decorative purposes are excluded. |
| 1.2.2 | 1.2.2 Captions (Prerecorded) | A | Provide captions for videos with audio | A YouTube video has captions that show what each person is saying. | Not required for media that is purely decorative. |
| 1.2.3 | 1.2.3 Audio Description or Media Alternative | A | Videos must have audio descriptions or a text alternative if important visuals aren’t explained in the audio. | A video shows a character being interviewed that nods in agreement. If the character only acknowledges silently, a description of the character's actions should be communicated. | Not required if visuals are already described in the audio. |
| 1.2.4 | 1.2.4 Captions (Live) | AA | Live videos must have captions. | A livestreamed event must include live captions. | Not required for media that is not livestreamed or has no audio during the streamed event. However closed captioning and transcripts should be available for recorded content. |
| 1.2.5 | 1.2.5 Audio Description (Prerecorded) | AA | Videos can be played with audio descriptions. | A video shows a character being interviewed that nods in agreement. If character only acknowledges silently a description of the characters actions should be communicated. | Not required if visuals are already described in the audio. |
| 1.3.1 | 1.3.1 Info and Relationships | A | Content must be structured using proper HTML so relationships are clear. | A table should not be built using <th> tags exclusively. | Purely visual formatting doesn’t require semantic markup. |
| 1.3.2 | 1.3.2 Meaningful Sequence | A | Content must be presented in a meaningful and logical order. | A webform should list fields in a logical order: address, city, state, zip code. | Not required if sequence doesn’t affect meaning. |
| 1.3.3 | 1.3.3 Sensory Characteristics | A | Instructions should not rely solely on visual references (color and shape). | Instead of saying “Click the round green button,” say “Click the green button labeled Submit.” | Not required if instructions are not essential. |
| 1.3.4 | 1.3.4 Orientation | AA | Content must work in both portrait and landscape modes of devices. | A webpage adjusts properly when you rotate your tablet. | Exceptions allowed if orientation is essential (e.g., piano app). |
| 1.3.5 | 1.3.5 Identify Input Purpose | AA | Input fields should be coded so browsers can autofill them. | Use an email field to capture email information instead of a text field. | Applies only to common input types (name, email, etc.). |
| 1.4.1 | 1.4.1 Use of Color | A | Color must not be the only way to convey information. | If a link labeled Apply Now is using a green style, the directions should not say "click the green button" but should say "click Apply Now". | Not required for decorative color use. |
| 1.4.2 | 1.4.2 Audio Control | A | Don't play audio automatically. | A website with a video should not play audio automatically. | Applies only to audio longer than 3 seconds or looping videos that are used for decorative purposes. |
| 1.4.3 | 1.4.3 Contrast (Minimum) | AA | Text must have enough contrast against its background. | Black text on white is easier to read than gray on yellow. | Not required for logos or incidental text. |
| 1.4.4 | 1.4.4 Resize Text | AA | Text can be resized to 200% without loss of content or function. | Users with blurry vision can increase font size without cutting off words or hiding buttons | Not required for captions, images of text, or text that’s part of a logo, brand name, or icon. |
| 1.4.5 | 1.4.5 Images of Text | AA | Don’t use images of text | Instead of using an image that reads “Apply Now”, use actual text so screen readers can read it. | Not required for logos, icons, or if the visual presentation is essential. |
| 1.4.10 | 1.4.10 Reflow | AA | Your website must be responsive. | A user using a mobile device or small screen, the text stacks vertically instead of cutting off. | Allowed for complex data visualizations such as charts and maps where reflow would lose meaning. |
| 1.4.11 | 1.4.11 Non-text Contrast | AA | Visual elements like buttons, icons, and focus indicators must have enough contrast against their background. | A green button on a green background is changed to white so it’s more visible. | Not required for decorative elements that don’t convey meaning. |
| 1.4.12 | 1.4.12 Text Spacing | AA | Users must be able to change spacing without breaking layout or hiding content. | A user increases line spacing to make reading easier and the page does not break. | Not required for images of text that are logos, icons, or brand names or canvas-based layouts. |
| 1.4.13 | 1.4.13 Content on Hover Focus | AA | If using tooltips or title tips, it must be dismissible, hoverable, and persistent. | A tooltip appears when you hover over an image until you move your mouse away. | Not required for keyboard inputs or if content is not dismissible by design. |
Operable
User interface components and navigation must be operable. Users should be able to interact with all functionality using different input methods, like a keyboard or voice commands—not just a mouse.
| Criteria | Success Criterion | Level | Description | Example | Exceptions |
|---|---|---|---|---|---|
| 2.1.1 | 2.1.1 Keyboard | A | All functionality must be available using a keyboard. This helps users who can’t use a mouse. | You can press Tab to move through a form and hit Enter to submit it. | Applies only to content that can be operated by a user. |
| 2.1.2 | 2.1.2 No Keyboard Trap | A | Users must be able to move in and out of interactive elements using a keyboard. | You can tab into a widget text block and tab out of it by tabing to the close button and clicking Enter/Return on your keyboard. | Not required if no keyboard functionality is provided. |
| 2.1.4 | 2.1.4 Character Key Shortcuts | AA | If single-key shortcuts are used, users should be able to turn them off or change them. | If pressing "D" deletes a file, you should be able to disable that shortcut. | Applies only to single-character shortcuts. |
| 2.2.1 | 2.2.1 Timing Adjustable | A | If a time limit is set, users must be able to extend or turn it off. | An application gives you the option to request more time before you are logged out. | Exceptions for real-time events, security, or essential time limits such as a time limited test. |
| 2.2.2 | 2.2.2 Pause, Stop, Hide | A | Moving, blinking, or scrolling content must be controllable. | A looping video has a pause button to stop it from moving automatically. | Applies only to content that starts automatically and lasts more than 5 seconds. |
| 2.2.3 | 2.2.3 No Timing | AAA | Users must be able to complete tasks without time limits. | A form lets you take as long as you need to fill it out. | Exceptions for real-time events or essential time limits. |
| 2.2.4 | 2.2.4 Interruptions | AAA | Users must be able to postpone or suppress interruptions. | You can turn off pop-up notifications while filling out a form. | Exceptions for emergency messages. |
| 2.2.5 | 2.2.5 Re-authenticating | AAA | Users must be able to continue their activity after re-authentication. | If you get logged out, your draft message is still saved. | Applies only to authenticated sessions. |
| 2.2.6 | 2.2.6 Timeouts | AAA | Users need to be warned of the duration of any inactivity that could cause data loss. | A web application provides a notice that the application will time out for security purposes. | This rule does not apply if the login method uses something the user has like a phone or security key. |
| 2.3.1 | 2.3.1 Three Flashes or Below Threshold | A | Content must not flash more than three times per second. | An animated image flashes slowly to avoid triggering epilepsy. | Applies only to full-screen flashing content. |
| 2.3.2 | 2.3.2 Three Flashes | AAA | No flashing is allowed, even below the threshold. | A video avoids any flashing effects entirely. | No exceptions. |
| 2.4.1 | 2.4.1 Bypass Blocks | A | Users must be able to skip repetitive content like navigation menus. | A "Skip to main content" link appears at the top of the page. | Applies only to pages with repeated blocks. |
| 2.4.2 | 2.4.2 Page Titled | A | Each page must have a descriptive title. | A basic page is titled "Admissions" instead of just "Home Page." | No exceptions. |
| 2.4.3 | 2.4.3 Focus Order | A | Keyboard focus allows users to navigate in a logical order. | Pressing Tab allows the user to navigate a page from top to bottom, not bottom to top. | Applies only to interactive content. |
| 2.4.4 | 2.4.4 Link Purpose (In Context) | A | The purpose of each link must be clear from its text or surrounding content. | A link that says"Download the Benefits Form" is clearer than "Click here." | Not required if link is ambiguous but context clarifies it. |
| 2.4.5 | 2.4.5 Multiple Ways | AA | Users must be able to find content using more than one method. | You can find a page using search, navigation, or a site map. | Not required for single-page sites. |
| 2.4.6 | 2.4.6 Headings and Labels | AA | Headings and labels must describe topic or purpose. | A form label says "Email Address" instead of just "Field." | Not required for decorative headings. |
| 2.4.7 | 2.4.7 Focus Visible | AA | The item you're interacting with via keyboard must be clearly highlighted. | Pressing Tab shows a blue outline around the button you're on. | Applies only to interactive elements. |
| 2.4.8 | 2.4.8 Location | AAA | Users must know where they are within a set of pages. | A breadcrumb trail shows "Home > Articles > Science." | Not required for single-page apps. |
| 2.4.9 | 2.4.9 Link Purpose (Link Only) | AAA | Link text alone must describe its purpose. | A link says "Download PDF" instead of "Click here." | No exceptions. |
| 2.4.10 | 2.4.10 Section Headings | AAA | Use headings to organize content. | A long article uses subheadings like "Introduction," "Methods," and "Conclusion." | Not required for short or simple content. |
| 2.5.1 | 2.5.1 Pointer Gestures | AA | Complex gestures like swiping or pinching must have simpler alternatives. | Instead of pinching to zoom, you can click a "+" button. | Applies only to multi-point gestures. |
| 2.5.2 | 2.5.2 Pointer Cancellation | AA | Actions triggered by pointer down events must be reversible or confirmed. | A button doesn’t submit a form until you release the mouse click. | Not required for simple clicks. |
| 2.5.3 | 2.5.3 Label in Name | AA | Labels on buttons and links must match what screen readers announce. | A button labeled "Search" is also called "Search" by the screen reader. | Applies only to visual labels. |
| 2.5.4 | 2.5.4 Motion Actuation | AA | If motion (like shaking or tilting) triggers actions, there must be another way to do it. | Instead of shaking your phone to undo, you can tap an "Undo" icon. | Exceptions allowed if motion is essential. |
| 2.5.5 | 2.5.5 Target Size | AAA | Touch targets must be large enough to avoid accidental taps. | A button is at least 44x44 pixels so it’s easy to tap. | Exceptions for inline links or essential small targets. |
| 2.5.6 | 2.5.6 Concurrent Input Mechanisms | AAA | Users must be able to switch between input methods. | You can use touch, keyboard, or voice to control the app. | Exceptions allowed if switching interferes with security or functionality. |
Understandable
Information and the operation of the user interface must be understandable. This means content should be clear, predictable, and easy to follow.
| Criteria | Success Criterion | Level | Description | Example | Exceptions |
|---|---|---|---|---|---|
| 3.1.1 | 3.1.1 Language of Page | A | The main language of the page must be identified in the code. This helps screen readers pronounce words correctly. | If a webpage is written in French, the screen reader uses a French voice. | Not required for pages with no text. |
| 3.1.2 | 3.1.2 Language of Parts | AA | If a section of content is in a different language, it must be marked. This helps screen readers switch pronunciation. | A Spanish quote in an English article is tagged so it’s read correctly. | Not required for proper names or technical terms. |
| 3.1.3 | 3.1.3 Unusual Words | AAA | Define or explain uncommon words or jargon. This helps users understand specialized content. | A glossary explains terms like "photosynthesis" and "mitosis." | Not required for common vocabulary. |
| 3.1.4 | 3.1.4 Abbreviations | AAA | Abbreviations must be defined or expanded. This helps users understand shortened terms. | "HTML" is explained as "HyperText Markup Language." | Not required for widely known abbreviations. |
| 3.1.5 | 3.1.5 Reading Level | AAA | Content must be written at a lower reading level or include support. This helps users with cognitive disabilities. | A complex article includes a summary written in plain language. | Not required for legal or technical documents. |
| 3.1.6 | 3.1.6 Pronunciation | AAA | Provide pronunciation help when needed to avoid confusion. | A name like "Bass" includes a note saying it rhymes with "class." | Not required unless pronunciation affects meaning. |
| 3.2.1 | 3.2.1 On Focus | A | When an element receives focus, it must not trigger unexpected changes. | When using your mouse to hover over a link, a new webpage should not be loaed. | Not required for intentional interactions. |
| 3.2.2 | 3.2.2 On Input | A | Changing a form field must not trigger unexpected actions. | Selecting a date shouldn’t automatically submit the form. | Allowed if user is warned in advance. |
| 3.2.3 | 3.2.3 Consistent Navigation | AA | Navigation menus must appear in the same order across pages. | The "Contact" link is always in the top right corner on every page. | Not required for pages with different layouts. |
| 3.2.4 | 3.2.4 Consistent Identification | AA | Elements with the same function must be labeled consistently. | A search box is always labeled "Search," not "Find" on one page and "Lookup" on another. | Not required if function changes. |
| 3.2.5 | 3.2.5 Change on Request | AAA | Changes to content or context must only happen when requested. | A dropdown menu doesn’t auto-refresh the page unless you click "Go." | Not required for essential automatic updates. |
| 3.3.1 | 3.3.1 Error Identification | A | If a user makes a mistake, the error must be identified. | If you leave a required field blank, the form should identify the required field and read as "This field is required." | Applies only to webform submission errors. |
| 3.3.2 | 3.3.2 Labels or Instructions | A | Forms must include labels or instructions. | An email form field says "Enter your email address." | Not required for obvious fields. |
| 3.3.3 | 3.3.3 Error Suggestion | AA | If a user makes a mistake in a form, the site should explain what went wrong and how to fix it. | If you forget your email, the site says "Please enter a valid email address." | Applies only when suggestions are known. |
| 3.3.4 | 3.3.4 Error Prevention (Legal, Financial, Data) | AA | Users must be able to review, confirm, and correct before final submission. | Before submitting payment, the site shows a summary so you can double-check your info. | Applies only to critical transactions. |
| 3.3.5 | 3.3.5 Help | AAA | Provide help for completing complex forms. | A form includes a help icon with tips for each section. | Not required for simple forms. |
| 3.3.6 | 3.3.6 Error Prevention (All) | AAA | Users must be able to review and correct all submissions. | A confirmation screen lets you edit your answers before submitting. | Applies only to irreversible actions. |
Robust
Robust means that websites and apps should work well with different technologies—like screen readers, browsers, and devices—now and in the future. Every button, link, or form field must have a name, role, and value that assistive technologies can recognize. This helps screen readers know what each element is and how to interact with it.
| Criteria | Success Criterion | Level | Description | Example | Exceptions |
|---|---|---|---|---|---|
| 4.1.1 | 4.1.1 Parsing | A | Code must be well-formed so assistive tech can interpret it. | A webpage uses correct HTML tags without missing brackets. | Applies only to markup languages. |
| 4.1.2 | 4.1.2 Name, Role, Value | A | UI components must have accessible names, roles, and values. | A checkbox is labeled "Subscribe" and screen readers know it’s a checkbox. | Applies only to custom components. |
| 4.1.3 | 4.1.3 Status Messages | AA | Important updates must be announced to screen readers. | After clicking "Register," the screen reader says "Registration complete." | Applies only to dynamic content changes. |