Accessibility - Draft Validation Rules

From MemberWiki

Jump to: navigation, search

Contents

Draft Validation Rules

This page contains the original validation rules drafted by the group during its early existence in the first part of 2009. These rules have been refined and organized according to WCAG 2.0 principles on the WCAG20 Validation Rules page. Hence, this page will eventually be deprecated and should not be used as a reference.

Rules definition supporting WCAG 2.0 Robustness

These are rules that:

  • validate the structure of WAI-ARIA widget roles based on the WAI-ARIA Best Practices Guide
  • identify unmarked live regions such as iframes and perceivable HTML divs with class information but no roles.
  • validate WAI-ARIA states and properties against WAI-ARIA roles. Global properties can be used throughout the page. Tests should be included to check these.
  • validate that an accessible name can be determined for WAI-ARIA roles. Given a role we can calculate a name
  • check WAI-ARIA states are applied to traditional form elements (Compare against existence of * for required form elements where aria-required is absent)
    • Note it's possible that WAI-ARIA properties like aria-required may be added in the DOM but not in the page source code.
  • identify content, such as tables used for formatting, that should be marked with role=presentation. Generate a warning when a presentation role is missing. For example if a table is missing a summary attribute or <th> elements, it may be a layout table.
  • validate use of the WAI-ARIA aria-hidden attribute
  • validate aria-valuenow is within range of aria-valuemin and aria-valuemax
    • Generate an error when widgets capable of accepting minimum and maximum values (e.g., slider, progress bar etc.) do not have aria-valuenow, aria-valuemin and aria-valuemax specified.
    • Generate an error when aria-valuenow is outside the range of aria-valuemin and aria-valuemax.
  • If invalid data is entered in a form field, validate that a WAI-ARIA aria-invalid attribute is added to the field.
  • indicate that a web application incorrectly change the value of a role attribute
  • Relationships –
    • Generate an error if form fields do not have an aria-labelledby or an html <label> tag.
    • If an action causes content to change in another area of a page, there must be a controls relationship between the element causing the action and the element containing the changed content.
    • If a large image does not have an aria-describedby attribute specified, generate a warning.
    • Test that there is an aria-controls relationship between a controlling element and the element it controls. For example a search button and search results element are related by setting an aria-controls on the search button that references the search results element. Another example, might be specifying an aria-controls relationship between a button that sends a chat message and the window element where the message appears (e.g., an element with a log role).
  • Live Regions
    • Generate a warning if a live region’s content changes and the region does not have focus. Rich, is this necessary? I’m pretty sure in my testing of live regions, updates were read regardless of whether the region had focus. Maybe JAWS was automatically focusing on the region??

Rules definitions supporting WCAG 2.0 Keyboard Accessible: Make all functionality available from a keyboard

  • Rules validating against use of tabindex and keyboard accessibility including the WAI-ARIA enhancement to the host language for tabindex="0" and "-1"
  • If possible, Rules validating against use of the WAI-ARIA keyboard style guide

Rules definitions supporting WCAG 2.0 Navigable: Provide ways to help users navigate, find content, and determine where they are.

These are rules that

  • Checks the use of WAI-ARIA landmarks to allow the browser or AT to render a UI to bypass blocks of content during navigation. There should be at least one main content area defined by a region with an ARIA role="main" or skip to main content link
    • If a page contains a collection of navigation links, a navigation landmark is required. Note that navigation links may be implemented as a menu. A warning is displayed if navigation links are discovered and no navigation landmark is found.
    • If a page contains a search field, a search landmark is required. Perhaps the page contains a search label to key off.
  • Ensure that non-application WAI-ARIA landmarks have a tabindex="0" set so that they are in the navigation order and place a user at the start of the navigation section. Ideally, there should be styling to highight the landmark region when it has focus (such as an outline border)
  • validate that ARIA landmarks, as specified by the ARIA specification, are labeled by an aria-labelledby relationship to the appropriate label text
  • define a set a criteria by which role of "document" and an "application" are set to assist screen readers with the navigation. For example, a role="application" would tell a screen reader to disable its browser keys and let the application take over.
  • validate that the "Focus order" follows the document order for ARIA widget containers, links, and form elements.
  • validate that the page has a title describing the topic or purpose.

Additional WCAG 2.0 rule and requirements

  • Definition: Violation: is a clear error.
  • Definition: Recommendation: Is an error to indicate that you do not conform to a best practice.
  • Definition: Potential Violation: We do not know if the condition has been met or not where user intervention is required to determine if it is a violation.
  • Definition: Potential recommendation: There is insufficient information to determine if you conform to a best practice but intervention is required. (e.g. keyboard handler exists but cannot tell if the developer met best practices for keyboard styling)
  • Limit our scope to A, AA compliance to WCAG 2.
  • Rules should be separated based on the requirement to support many to many.
  • If non-text content should be ignored by assistive technology:
    • If an image is marked presentational but alt text provided or a title generate a "recommendation."
    • If an image is found with null alt text, no title should be present. Therefore, if an image is found with null alt text and a title is present, generate a "recommendation."
  • Link text must describe the purpose of a link. Therefore, link text must be some alphanumeric characters otherwise it is a "potential violation."
  • Generate a "violation" when the alt attribute is missing from an image. Generate the same "violation" when the alt attribute is missing from area elements and input elements of type "image".
  • Generate a "violation" if alt text is found to have any of the common file extensions (e.g., .pdf, .doc etc.) indicating that the alt attribute contains a file name.
  • Generate an "violation" when any of the following "trimmed" placeholder text is found such as an exact match in an alt attribute: " ", "image", "picture" "graph." If have a single word that is not in this list mark as a "potential violation." We should look to expand this list. Note: for other languages, language equivalents are violations. May need refinement
  • Generate a "potential violation" if the text content of an <object> or <applet> element is empty.
  • If the text content for the <object> or <applet> generate a "potential violation" if the text does not describe it.
  • Jon to edit the rule for processing the audio file reference
  • Generate a "potential violation" if the an <object> element sources a sound file. If any audio on a Web page plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume independently from the overall system volume level. Our rules should include the set of audio file types to limit the number of potential violations.
  • If it can be determined that a multimedia file is present, generate a violation if the alternative content does not validate. If a alternative format cannot be determined generate a potential violation:
  • Separate information and structure from presentation to enable different presentations.
    • If the style attribute is found on any element and no ARIA role is provided, generate a potential violation that says structure and presentation should be separated.
    • When style is found on an element and color is a style attribute, generate a potential violation that color alone should not convey information only if the style is not formed using a CSS attribute selector tied to a known attribute in the host language or a WAI-ARIA state and property. (Later browsers browsers support attributed CSS attribute selectors)

Headings

  • If text is wrapped in HTML bold tags generate a violation in the following forms:
    • If text is wrapped in HTML decorative tags followed or preceded by a "br" tag, generate the violation: "Use HTML headings instead of simulating headings with bold markup."
    • Otherwise if the bold element does not contain ARIA markup for role="header" and aria-level="x" generate: Do not use text decoration or color as the only way to add meaning. Additionally, use HTML headings instead of simulating headings with bold markup." unless the bold element contains
    • Definition decorative: bold, strong, font size
  • When the class attribute is to have "head" as part of the class name (e.g., heading1, heading2, head1, etc.) and the element is not a heading element (e.g., h1, h2, etc.). Generate a warning that an HTML heading should be used instead of simulating a heading with CSS.
  • If innerHTML, outerHTML or document.write is found, generate a warning that DOM functions should be used to add content to a page.

Layout Tables

  • Layout tables should not contain <th> or a summary attribute. If a table is found to contain one of these, the other must be present or a warning message is generated.
    • Tests for layout table: role="presentation." In this scenario generate a violation.
    • A one by one table. In this scenario generate a violation.
    • If we detect a TD or ROLE=COLUMNHEADER there is not an adequate number of these that we flag a violation, that the author needs to determine if it is a data table or a layout table and use the proper markup for that table. For presentational tables suggest provide role="presentation" on the table. For data tables fill out the appropriate header information (ARIA columnheaders and rowheaders or HTML <TH> elements)
    • Group needs to create adequate test cases to vet this out.

Data Tables

  • Generate an violation when a data table is missing a "summary" or a aria-describedby.
  • Use these rules as a starting point for data table detection: http://html.cita.uiuc.edu/nav/dtable/dtable-rules.php
  • Some test pages for data tables http://test.cita.illinois.edu/html-bp/nav/dtable/
    • Regarding data tables, generate a potential recommendation to say: "If you have a caption associated with this data table you should associate it using aria-labelledby. The group is concerned about using the caption element due to problems with the way ATs process the caption element. aria-labelledy is more consistent across HTML and other markup languages.
    • Regarding data tables, if it is determined to be a datatable generate a violation when a table summary is not provided or aria-describedby is not used to associate a summary with the data table.
  • Information, structure, and relationships conveyed through presentation should be programmatically determined or are available in text. Generate a warning if the HTML pre element is encountered. The pre element may indicate manual formatting.

Adaptable

  • Because we are testing dynamically, we believe that testing formal document structure semantics through HTML and ARIA analysis for widgets and live regions should suffice vs. using the the test document.write() and innerHTML to indicate a failure. We should take this up with the WCAG 2 working group. Group agrees that we will not test for the use of document.write and inner.html.
  • Use of any stylistic, deprecated HTML markup should result in a violation: bold, blink, marquee, u (underlined text), i (italicize)

Event Handlers

  • Rules when event handlers can be programmatically determined
    1. A elements with onMouseOver and onMouseOut event handlers must either: move hover effects to CSS or include onFocus and onBlur event handlers that emulate the effects
    2. Elements that include a ROLE attribute must include a keyboard event handler (onKeyDown, onKeyUp or onKeyPress) on the container element for the widget: example the element with ROLE="TREE" in a tree widget must have keyboard event handlers
    3. Elements that include onMouseXXX event handlers must include a ROLE and one of the following:
      1. If ACTIVE-DESCENDANT is being used the container must have a TABINDEX value greater than or equal to "0" or
      2. At least one child element with an associated child ROLE must have a TABINDEX value, the value is based on the type of widget containers
  • Rules when event handlers cannot be programmatically determined (but may be visible in markup)
    1. Anchor (link) elements with onMouseOver and onMouseOut events defined in HTML markup must either: move hover effects to CSS or include onFocus and onBlur events. If not it is considered a Violation.
    2. Elements that include a ROLE attribute in markup must recommend a manual check for keyboard support. This is not all roles. Only roles that will manage the keyboard (grid, tree, tablist, menubar, menu, button, checkbox, listbox, list, etc.). You would not put tests on treeitem, menuitem, or gridcell. Note: the managed roles may have mouse handlers on them for which we don't want to check for keyboard equivalents.)
    3. If 2 is true a manual check for visual focus must recommended.
    4. Any non-form or non-anchor element that has an event handler and does not not have a role generate a Violation
    5. Elements that include onMouseDown or onMouseUp event in markup must recommend a manual check for keyboard support

Miscellaneous Rules pertaining to ARIA

    1. ROLE values whose syntax is incorrect based on ARIA RDF descriptions generate a Violation based on the Robust section of WCAG 2
    2. A container role ROLE (tree, grid, menu, etc.) must have at least one child with a applicable role as defined by ARIA otherwise generate a Violation based on Robust section of WCAG 2.
    3. Coding patterns for ROLE are consistent. If a container role has a child without missing a role as defined by the ARIA best practices guide generate a potential violation (e.g. a div in a grid without a gridcell role).
    4. Elements with ROLE values must also have TABINDEX defined and with the correct value for TABINDEX (i.e. a TREE would have TABINDEX=0 and a TREEITEM=-1) unless the element's corresponding container makes use of aria-activedescendant.

Link Content Calculation

  • Text nodes
  • Equivalents for non-content (i.e. IMG[ALT], AREA[ALT], ... )

Titling Rules

Principle: Title of a web page should describe the overall web site/application and sub page or functional unit of the application

http://www.w3.org/WAI/WCAG20/quickref/#qr-navigation-mechanisms-title

Best Practice Model

  • TITLE element contains web site and sub page information
  • H1 contains at least sub page information and can contain web site information

Rules

  1. Generate a violation when a web page does not have a TITLE element
  2. Generate a violation when the TITLE element does not contain content
    • at least one non-space character
    • Language dependent rules??
  3. Generate a warning when a web page does not have an H1 element
  4. Generate a warning when a web page has more than 2 H1 elements
  5. Generate a warning when a H1 element does not contain content
  6. Generate a warning when the content (words) of the H1 element(s) is not contained in the TITLE element

Titling Frames

Principle: In general using frame titles is a poor navigation technique, headers and other landmark roles are much better and easier people with disabilities to navigate a page.

WCAG 2.0

Rules

  1. Generate a violation if a Frame does NOT have a TITLE attribute defined or is marked as ROLE=PRESENTATION
  2. If the frame content is rendered (not hidden) the TITLE content should describe the contents of the frame (manual check)

Link Rules

Link Issues
  • Is uniqueness of a link the primary way to measure "purpose of a link"
  • What are the cases that cases failure of 2.4.4 we want to test
Proposed Rules 2.4.4
  1. If the Link text has a URL generate a Violation
  2. Generate an Violation when the link text is empty or only contains normalized spaces
  3. If the link has an image the above rules apply for alternative text
  4. An image that is the entire content of a link should be at least 16x16 pixels in size. (Best Practice)
  5. For links that include an img element and text content, the alt attribute content of the img element should not repeat the text content of the link. If it does generate a Violation. Images that are the used as icons to help users identify the purpose of a link should have their alt attribute set to empty or be included in the graphical rendering as a CSS background image. (Best Practice)
  6. Tests for uniqueness of links within a context (Best Practices where failure would generate a Violation)
    1. Links pointing to different URLs who share the same LI, P, TD or TH container element must have unique text content within the container element and one of the following conditions:
    2. The text content of the containing LI, P, TD, TH must be unique when compared to other links or calculated context, or
    3. The text content of the link when combined with the first preceding heading element content must be unique when compared to other links or calculated context, or
    4. If a link is the child of nested LI elements, the parent and grand parent LI content when combined must must be unique from other links or calculated context on the page
    5. The TITLE or ARIA-DESCRIBEDBY content for the link is unique
Proposed Rules 2.4.9
  1. The text content of a link is not at least 4 characters (for Western character sets) in length when rendered graphically generate a violation. (Best Practice)
  2. Link text should be meaningful when taken out of context (WCAG AAA)
    • Links that point to different URIs should have different text contents otherwise generate a violation.
    • Generate a Potential Violation for links that point to the same URL but don't have the same link text (Best Practice)

Language Rules

  • Generate a violation when an HTML lang attribute is missing.
  • Best Practice: when language switching occurs within the page ensure that the lang attribute is set properly for that section. If not, generate a warning. This would be through visual inspection.

Form Labeling Rules and Instructions (Refers to WCAG 2.0 checkpoint 3.3.2)

  1. The elements input[type="text | password | checkbox | radio | file"], select and textarea must have:
    • label element content that has the label.for attribute referencing the id attribute of the form control element, or
    • title attribute content on the form control element, or
    • aria-labelledby attribute on the form control element, or
    • aria-label attribute on the form control element
  2. The element input[type="image"] must have:
    • alt attribute content on the form control element itself, or
    • title attribute content on the form control element itself or
    • aria-labelledby attribute on the form control element, or
    • aria-label attribute on the form control element
  3. The elements input[type="button" | submit | reset"] must have:
    • value attribute content on the form control element itself, or
    • title attribute content on the form control element itselfor
    • aria-labelledby attribute on the form control element, or
    • aria-label attribute on the form control element
  4. Each label and legend element must contain content that helps identify the purpose of the form control on the page. If the title attribute is defined for an input. select, textarea or button element, it must also contain content since it will be used by assistive technologies as part of the effective label for the form control.
  5. If a form control has an id attribute its value must be unique on the page.
  6. Each effective label within a page should be unique otherwise it generate a Violation.
  7. Any text within a form but have an label.for attribute set to an id within the form or it must have an id and be referenced by aria-labelledby or aria-descrbideby from actual form or a form element within the form. If not, the text must be marked with a role="presentation" otherwise generate a Violation.
  8. Required form controls should have the word "required" as part of the effective label or use the aria-required attribute on the form control otherwise it is a Violation.
  9. If the form element has both required in its label and aria-required="true" generate a Recommendation to the author that they only set aria-required="true" and show visual indication that the element is required such as through use of an asterisk.
  10. Error Identification WCAG 3.3.1
    1. If aria-invalid attribute set on a form control check to see that an aria-describedby is provided in prose on the page which may indicate that there is an error and the nature of it or that aria alert gets created. Otherwise, generate a Potential Violation.
    2. Optional Manual Test: When content of a form is validated as the user submits the form, a response page that provides a list of links with each link text describing the problem with each invalid form field should follow.
    3. Optional Manual Test: When content of a form is validated as the user fills out each form field, an alert message must indicate if the input is invalid as the user tries to move the focus to the next form control
  11. Manual Test: Ensure that form fields are in a logical tabbing order. Provide optional guidance to the author in report.
  12. If an asterisk or the word "required" is found, in a form label (i.e., <form> </form>) and aria-required isn't present, generate a Potential Violation that an aria-required attribute must be specified on fields that are required.

Parsing WCAG 2 Guideline 4.1.1

  • Prior to loading the document, generate a Violation when:
    • a document type is not provided
    • The document does not validate
    • Document elements have incomplete start and end tags
    • Document elements contain duplicate attributes
    • elements are not nested according to their specifications
  • At run time generate a Violation when elements
    • IDs are not unique

Pause Stop and Hide WCAG checkpoint 2.2.2

  • For regions marked with the aria-live property generate a notification to perform the following Manual Tests:
    • For any auto-updating information that (1) starts automatically and (2) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it or to control the frequency of the update unless the auto-updating is part of an activity where it is essential. If not this is a Violation.
    • For any moving, blinking or scrolling information that (1) starts automatically, (2) lasts more than five seconds, and (3) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it unless the movement, blinking, or scrolling is part of an activity where it is essential. If not this is a Violation.

Best Practices Reporting Schemes for IDEs

Best Practices Reporting Schemes for Test tools for Rich Internet Applciations

  • Comment on reporting: Users are asking for reports that document exactly what's been tested. For example, for Web crawlers, they are asking for a list of URLs that have been crawled. And perhaps those URLs that have been excluded (some tools enable users to exclude URLS from a crawl). (DT)
Retrieved from "/member/wiki/Accessibility_-_Draft_Validation_Rules"
Personal tools