ARIA Rules Overview.

Based on the Web Content Accessibility Guidelines, Level A conformance was a basic requirement for some groups to be able to use web documents. Level AA conformance indicated better accessibility and removal of significant barriers to accessing the content. Level AAA checkpoints provided improvements to web content accessibility. The following are the lists for ARIA rules categorized by three different levels.

  • Level A:

  • Level AA:

  • Level AAA:

    • ARIA_1: Using the aria-describedby property to provide a descriptive label for input controls.

    The purpose of this technique is to demonstrate how to use the WAI-ARIA aria-describedby property to provide programmatically determined, descriptive information about a user interface element. The aria-describedby property may be used to attach descriptive information to one or more elements through the use of an id reference list. The id reference list contains one or more unique element ids.

    Example for aria-describedby: checkbox.
    Full description for ARIA1.

    ARIA_2: Identifying required fields with the aria-required property.

    The objective of this technique is to indicate in a programmatically determinable way that the completion of a user input field is mandatory. The WAI-ARIA aria-required property indicates that user input is required before submission. The aria-required property can have values of "true" or "false". For example, if a user must fill in an address field, then aria-required is set to "true".

    Example for aria-required: tooltip.
    Full description for ARIA2.

    ARIA_3: Identifying valid range information with the aria-valuemin and aria-valuemax properties.

    The objective of this technique is to provide information about the allowable range of an entry field in a programmatically determinable way. The WAI-ARIA aria-valuemin and aria-valuemax states provide the minimum and maximum (respectively) values that may be provided by the user. Some user agents will not permit users to enter values outside that range, or will generate a validation error if users do so. The developer is still responsible for providing validation that the value is within the range.

    Example for aria-valuemin / aria-valuemax: progressbar.
    Full description for ARIA3.

    ARIA_4: Using a WAI-ARIA role to expose the role of a user interface component.

    The objective of this technique is to define the role of an element using the role attribute with one of the non-abstract values defined in the WAI-ARIA Definition of Roles. The WAI-ARIA specification provides an informative description of each role, how it relates to other roles, and the states and properties for each role. When rich internet applications define new user interface widgets, exposing the roles enables users to understand the widget and how to interact with it.

    Full description for ARIA4.

    ARIA_5: Using WAI-ARIA state and property attributes to expose the state of a user interface component.

    The objective of this technique is to use WAI-ARIA state and property attributes to expose the state, properties and values of a user interface component so that they can be read and set by assistive technology, and so that assistive technology is notified of changes to these values. The WAI-ARIA specification provides a normative description of each attribute, and the role of the user interface elements that they support. When rich internet applications define new user interface widgets, exposing the state and property attributes enables users to understand the widget and how to interact with it.

    Full description for ARIA5.

    ARIA_6: Using aria-label to provide labels for objects.

    The purpose of this technique is to provide a label for objects that can be read by assistive technology. The aria-label attribute provides the text label for an object, such as a button. When a screen reader encounters the object, the aria-label text is read so that the user will know what it is.

    Full description for ARIA6.

    ARIA_7: Using aria-labelledby for link purpose.

    With the aria-labelledby attribute, authors can use a visible text element on the page as a label for a focusable element (a form control or a link). For example, a "read more..." link could be associated with the text of the heading of the preceding section to make the purpose of the link unambiguous.

    Full description for ARIA7.

    ARIA_8: Using aria-label for link purpose.

    The objective of this technique is to describe the purpose of a link using the aria-label attribute. The aria-label attribute provides a way to place a descriptive text label on an object, such as a link, when there are no elements visible on the page that describe the object. If descriptive elements are visible on the page, the aria-labelledby attribute should be used instead of aria-label. Providing a descriptive text label lets a user distinguish the link from links in the Web page that lead to other destinations and helps the user determine whether to follow the link. In some assistive technologies the aria-label value will show in the list of links instead of the actual link text.

    Full description for ARIA8.

    ARIA_9: Using aria-labelledby to concatenate a label from several text nodes.

    The aria-labelledby property can be used to label all visual objects. Applied to inputs, the aria-labelledby property can be used to label native inputs as well as non-native elements, such as custom text inputs constructed with div contenteditable="true".

    Full description for ARIA9.

    ARIA_10: Using aria-labelledby to provide a text alternative for non-text content.

    The purpose of this technique is to provide a short description for an element that can be read by assistive technologies (AT) by using the aria-labelledby attribute. The aria-labelledby attribute associates an element with text that is visible elsewhere on the page by using an ID reference value that matches the ID attribute of the labeling element. Assistive technology such as screen readers use the text of the element identified by the value of the aria-labelledby attribute as the text alternative for the element with the attribute.

    Full description for ARIA10.

    ARIA_11: Using ARIA landmarks to identify regions of a page.

    The purpose of this technique is to provide programmatic access to sections of a web page. Landmark roles (or "landmarks") programmatically identify sections of a page. Landmarks help assistive technology (AT) users orient themselves to a page and help them navigate easily to various sections of a page.

    Example for ARIA landmarks.
    Full description for ARIA11.

    ARIA_12: Using role=heading to identify headings.

    The purpose of this technique is to provide a way for Assistive Technologies (AT) to identify a piece of content as a heading. Applying role="heading" to an element causes an AT (like a screen reader) to treat it as though it were a heading.

    Full description for ARIA12.

    ARIA_13: Using aria-labelledby to name regions and landmarks.

    The purpose of this technique is to provide names for regions of a page that can be read by assistive technology. The aria-labelledby attribute provides a way to associate an section of the page marked up as a region or landmarks with text that is on the page that labels it.

    Full description for ARIA13.

    ARIA_14: Using aria-label to provide an invisible label where a visible label cannot be used.

    For sighted users, the context and visual appearance of an element can provide sufficient cues to determine the purpose. An example is the 'X' often used in the top right corner of pop-up divs (light boxes) to indicate the control for closing the div.

    In some situations, elements can be given the attribute aria-label to provide an accessible name for situations when there is no visible label due to a chosen design approach or layout but the context and visual appearance of the control make its purpose clear.

    In other situations, elements can be given the attribute aria-label to provide an accessible name when the native HTML labeling element is not supported by the control - for example, when a div set to contentEditable is used instead of native form elements such as input type="text" or textarea in order to provide a richer text editing experience.

    Full description for ARIA14.

    ARIA_15: Using aria-describedby to provide descriptions of images.

    The objective of this technique is to provide descriptions of images when a short text alternative does not adequately convey the function or information provided in the object.

    A feature of WAI-ARIA is the ability to associate descriptive text with a section, drawing, form element, picture, and so on using the aria-describedby property. This is similar to the longdesc attribute in that both are useful for providing additional information to help users understand complex images. Like longdesc, descriptive text provided using aria-describedby is separate from the short name provided using the alt attribute in HTML. Unlike longdesc, aria-describedby cannot reference descriptions outside of the page containing the image. An advantage of providing long descriptions using content from the same page as the image is that the alternative is available to all, including sighted people who do not have assistive technology. It is worth noting that as of the time of writing (October 2013) some assistive technologies read aria-describedby content immediately after an image's alt attribute information without user activation - whereas most implementations of longdesc require the user to take explicit action to read the additional description.

    Full description for ARIA15.

    ARIA_16: Using aria-labelledby to provide a name for user interface controls.

    The purpose of this technique is to provide names for user interface controls that can be read by assistive technology. WAI-ARIA provides a way to associate text with a section, drawing, form element, picture, and so on, using the aria-labelledby property. This techniques uses the aria-labelledby attribute to associate a user interface control, such as a form field, with text on the page that labels it.

    Full description for ARIA16.

    ARIA_17: Using grouping roles to identify related form controls.

    The objective of this technique is to mark up a set of related controls within a form as a group. Any label associated with the group also serves as a common label or qualifier for individual controls in the group. Assistive technologies can indicate the start and end of the group and the group’s label as one navigates into and out of the group. This is a viable alternative for grouping form controls programmatically when the user interface’s design makes it difficult to employ the fieldset-legend technique.

    Full description for ARIA17.

    ARIA_18: Using aria-alertdialog to Identify Errors.

    The purpose of this technique is to alert people that an input error has occured. Using role="alertdialog" creates a notification. This notification should be modal with the following characteristics:

  • aria-label or aria-labelledby attribute gives the alertdialog an accessible name.
  • aria-describedby provides a reference to the text of the alert.
  • The alertdialog contains at least one focusable control, and the focus should move to that control when the alertdialog opens.
  • The tab order is constrained within the alertdialog whilst it is open.
  • When the dialog is dismissed, the focus moves back to the position it had before the dialog opened, if possible.

    • Full description for ARIA18.

    ARIA_19: Using ARIA role=alert or Live Regions to Identify Errors.

    The purpose of this technique is to notify Assistive Technologies (AT) when an input error occurs. The aria-live attribute makes it possible for an AT (such as a screen reader) to be notified when error messages are injected into a Live Region container. The content within the aria-live region is automatically read by the AT, without the AT having to focus on the place where the text is displayed.

    Full description for ARIA19.

    ARIA_20: Using the region role to identify a region of the page.

    This technique demonstrates how to assign a generic region role to a section of a page so that user agents and assistive technologies may be able to programmatically identify it. The region role demarcates a segment of the page that contains content of significance so that it is more readily discoverable and navigable. The generic region should be used when the section cannot be marked up using a standard document landmark role (see ARIA11).

    It is important to name regions, because they are generic grouping elements and users will need some way to tell which region they are in. Regions can be named using aria-labelledby, aria-label, or another technique. Doing so helps to better expose content and information relationships on the page. The role of region should be used prudently, because if overused they can make the page overly verbose for screen reader users.

    Full description for ARIA20.

    ARIA_21: Using Aria-Invalid to Indicate An Error Field.

    This technique demonstrates how aria-invalid may be employed to specifically identify fields that have failed validation. Its use is most suitable when:

  • The error description does not programmatically identify the failed fields
  • The failed fields are identified in a manner that is not available to some users - for example by using an error-icon rendered visually by some technique that does not rely on color such as a visual cue like a border.

    • Full description for ARIA21.

    More Information

    To see full W3C Web Content Accessibility Guidelines (WCAG) 2.0, please check the following link: Guildlines

    Functional Accessibility Evaluator 2.0

    Authors and Contributors

    Achin Kulshrestha, Akshay Uttamani, Chih-Ching Chang

    Support or Contact

    Having trouble with Pages? Check out our documentation or contact support and we’ll help you sort it out.