Web Accessibility Flashcards
Page Language: The primary language of the page MUST be identified accurately, using a standard language code, on the element
lang=”en” or lang=”fr”>
Language of Parts: Inline language changes MUST be identified with a valid
lang attribute.
Two-character language code: The language code SHOULD be designated with a standard two-character ISO 639-1 code (e.g. lang=”en”) to achieve maximum support across screen readers and browsers, though other codes
(e.g. lang=”en-us”) are technically allowable.
Bypass blocks:
Screen readers allow users to navigate by headings, so headings are an effective way to bypass blocks of content, as required by WCAG 2.4.1. Note: Headings are not absolutely required by WCAG to pass 2.4.1, but are highly recommended, along with landmarks and skip links.
Accurate, informative section labels: Headings MUST be accurate and informative, as labels for the sections of text they describe.
Brevity: Heading text SHOULD be concise and relatively brief.
Use real headings: Text that acts as a heading visually or structurally SHOULD be designated as a true heading (<h1>, </h1><h2>, etc.) in the markup.</h2>
Heading Markup for Headings Only: Text that does not act as a heading visually or structurally SHOULD NOT be marked as a heading.
Content outline: Headings SHOULD convey a clear and accurate structural outline of the sections of content of a web page.
Consecutive levels: Headings SHOULD NOT skip hierarchical levels.
Bypass blocks: Screen readers allow users to navigate by landmarks, so landmarks are an effective way to bypass blocks of content, as required by WCAG 2.4.1. Other methods may be used as well as — or instead of — landmarks, such as skip links, headings, expand/collapse regions, etc.
Page layout groupings: Landmarks SHOULD be used to accurately designate pre-defined parts of the layout (e.g. the header, navigation, main content, and footer).
Content within landmarks: All text SHOULD be contained within a landmark region.
Landmark names: Multiple instances of the same type of landmark SHOULD be distinguishable by different discernible names (using aria-label or aria-labelledby).
Only one instance of some landmarks: A page SHOULD NOT contain more than one instance of each of the following landmarks: header/banner, main, and footer/contentinfo.
Markup: Landmarks MAY be designated with either HTML tags or their equivalent ARIA roles (e.g. or role=”banner”, or role=”navigation”, or role=”main”, or role=”contentinfo”, etc.).
List markup: Lists MUST be constructed using the appropriate semantic markup (i.e. <ul> or </ul><ol> with <li> child elements, or <dl> with <dt> and </dt><dd> child elements).</dd></dl></li></ol>
Header tag: Table headers MUST be designated with .
Meaningful header: Data table header text MUST accurately describe the category of the corresponding data cells.
Header and data cell associations: Table data cells MUST be associated with their corresponding header cells. Note: Use of scope ( and ) is highly recommended, though not always necessary (i.e. if all cells in the first row are marked as without scope, most modern screen readers will infer that the scope is the column below each header cell).
Group header associations: Table data group headers (if any) MUST be associated with their corresponding data cell groups (e.g. via scope=”rowgroup” or scope=”colgroup”).
Complex header associations: Header/data associations that cannot be designated with and scope MUST be designated with the headers and id attributes.
Nested or split tables: Data table headers and data associations MUST NOT be referenced across nested, merged, or separate tables.
Tables: Tabular data SHOULD be represented in a . Note: Even if the data are not represented in a table, WCAG 1.3.1 requires the data to be associated with their labels.
Caption: Data tables SHOULD have a programmatically-associated or name (e.g. via aria-label or aria-labelledby). Note: In most circumstances, is preferred, because it is the native method of giving a name to a table, and the is visible and available to all users by default.
Meaningful caption: The name or of a data table SHOULD describe the identity or purpose of the table accurately, meaningfully, and succinctly.
Unique caption: The name or of each data table SHOULD be unique within the context of other tables on the same page.
Avoid layout tables: Tables SHOULD NOT be used for the purpose of purely visual (non-data) layout.
Avoid headers in layout tables: Layout tables MUST NOT contain headers.
Meaningful iframe title attribute: The iframe title attribute (on the parent page) MUST be accurate and descriptive.
Unique title attributes: Every iframe SHOULD have a unique title (in the context of the page).
Hidden or empty iframes: Hidden frames or frames that do not convey content to users SHOULD be hidden from assistive technologies using aria-hidden=”true”.
Page title of embedded page: The source page of an iframe (the page embedded in the iframe) MUST have a valid, meaningful .
Unique IDs: IDs MUST be unique within a web page.
Unique Names: The “accessible names” of elements, when provided, of block level elements (e.g. landmarks, tables, iframes, etc.) SHOULD be unique within a web page.
Note: The accessible name is determined by attributes or elements such as aria-label, aria-labelledby, alt, , etc. Refer to the Accessible Name and Description Computation for details.
Closing Tags: Elements must not be missing closing tags. DIV or P element must not be nested within a LABEL element. Element must not contain duplicate attributes.
Required WCAG 4.1.1
Parent-Child Relationships: Markup MUST adhere to required parent-child relationships of elements and attributes.
Parent-Child Relationships: Markup MUST adhere to required parent-child relationships of elements and attributes.
Required WCAG 4.1.1
ARIA relationships: ARIA relationships (e.g. parent-child, aria-owns, etc.) SHOULD adhere to WAI-ARIA Authoring Practices
Required WCAG 4.1.1
Deprecated Markup should not be used.
Best practice
Emphasis: Critical emphasis in the text SHOULD be conveyed in a text-based format, not visual styling alone.
Best practice
Highlighting markup: Highlighted text SHOULD be marked with the element.
Best practice
Text-based highlighting: Critical highlighted text SHOULD be supplemented with a text-based method to convey the meaning of the highlighting.
Best practice
Blockquote: The <blockquote> element SHOULD be used to designate long (block level) quotations.
Best practice</blockquote>
Indentation: The <blockquote> element SHOULD NOT be used for visual styling (indentation) alone.
Best practice</blockquote>
Inline quotations: The element (for inline quotations) SHOULD NOT be used as the only way to designate quotations, due to poor support in screen readers and some browsers.
Best practice
Strikethrough markup: Strikethrough text SHOULD be marked with the <del> element.
Best practice</del>
Strikethrough supplemental text: Critical strikethrough text MUST be supplemented with a text-based method to convey the meaning of the strikethrough.
Best practice
Insert markup: Text designated for insertion SHOULD be marked with the <ins> element.
Best practice</ins>
Insert supplemental text: Critical text designated for insertion MUST be supplemented with a text-based method to convey the meaning of the insertion.
Best practice
Link markup: Links MUST be semantically designated as such.
Note: Ideally this means using an <a> element with a valid href value. In rare problematic cases, setting role=”link” (and adding all other aspects of link functionality) may be acceptable.
Required WCAG 4.1.2</a>
Links versus buttons: Links SHOULD be used only for actions that take the user to other locations and SHOULD NOT be used for button-like functionality.
Note 1: “Other locations” means other web pages, or to other locations in the same web page. Typically, the URL will change after activating a link.
Note 2: “Button-like functionality” means scripted features, including submitting forms.
Best practice
Discernible text: A link MUST have programmatically discernible text, as determined by the accessible name calculation algorithm.
Required WCAG 4.1.2
Distinguishable link purpose: The purpose of each link MUST be understandable and distinguishable from other links on the same page, either from the link text alone (ideally), or from the immediate surrounding context of the link.
Required WCAG 2.4.4
Avoid “link” (or similar) in the link text: The link text SHOULD NOT state its semantic role (e.g. don’t say “link to…”), because screen readers already state the role before reading the link text.
Best practice
Consistent link text across pages: Links to the same destinations MUST be consistently identified with the same (or very similar) link text across all pages of the site.
Required WCAG 3.2.4
Links opening in new tab or window: A link that opens in a new window or tab SHOULD indicate that it opens in a new window or tab.
Best practice
