diff --git a/index.html b/index.html index ebba143db..c4cd4cfb6 100644 --- a/index.html +++ b/index.html @@ -246,7 +246,7 @@

Co-Evolution of WAI-ARIA

WAI-ARIA is intended to augment semantics in supporting languages like [[HTML]] and [[SVG2]], or to be used as an accessibility enhancement technology in other markup-based languages that do not explicitly include support for ARIA. It clarifies semantics to assistive technologies when authors create new types of objects, via style and script, that are not yet directly supported by the language of the page, because the invention of new types of objects is faster than standardized support for them appears in web languages.

It is not appropriate to create objects with style and script when the host language provides a semantic element for that type of object. While WAI-ARIA can improve the accessibility of these objects, accessibility is best provided by allowing the user agent to handle the object natively. For example, it's better to use an h1 element in HTML than to use the heading role on a div element.

It is expected that, over time, host languages will evolve to provide semantics for objects that currently can only be declared with WAI-ARIA. This is natural and desirable, as one goal of WAI-ARIA is to help stimulate the emergence of more semantic and accessible markup. When native semantics for a given feature become available, it is appropriate for authors to use the native feature and stop using WAI-ARIA for that feature. Legacy content can continue to use WAI-ARIA, however, so the need for user agents to support WAI-ARIA remains.

-

While specific features of WAI-ARIA might lose importance over time, the general possibility of WAI-ARIA to add semantics to web pages is expected to be a persistent need. Host languages might not implement all the semantics WAI-ARIA provides, and various host languages can implement different subsets of the features. New types of objects are continually being developed, and one goal of WAI-ARIA is to provide a way to make such objects accessible, because web authoring practices often advance faster than host language standards. In this way, WAI-ARIA and host languages both evolve together but at different rates.

+

While specific features of WAI-ARIA might lose importance over time, the general possibility of WAI-ARIA to add semantics to web pages is expected to be a persistent need. Host languages might not implement all the semantics WAI-ARIA provides, and various host languages can implement different subsets of the features. New types of objects are continually being developed, and one goal of WAI-ARIA is to provide a way to make such objects accessible, because authoring practices often advance faster than host language standards. In this way, WAI-ARIA and host languages both evolve together but at different rates.

Some host languages exist to create semantics for features other than the user interface. For example, SVG expresses the semantics behind production of graphical objects, not of user interface components that those objects can represent. Host languages might, by design, not provide native semantics that map to WAI-ARIA features. In these cases, WAI-ARIA could be adopted as a long-term approach to add semantic information to user interface components.

@@ -432,7 +432,7 @@

All WAI-ARIA in <

Assistive Technology Notifications Communicated to Web Applications

Assistive technologies, such as speech recognition systems and alternate input devices for users with mobility impairments, require the ability to control a web application in a device-independent way. WAI-ARIA states and [=ARIA/properties=] reflect the current state of rich internet application components. The ability for assistive technologies to notify web applications of necessary changes is essential because it allows these alternative input solutions to control an application without being dependent on the standard input device which the user is unable to effectively control directly.

-

User agents MUST provide a method to notify the web application when a change occurs to states or properties in the system accessibility API. Likewise, web application authors SHOULD update the web application accordingly when notified of a change request from the user agent or assistive technology.

+

User agents MUST provide a method to notify the web application when a change occurs to states or properties in the system accessibility API. Likewise, authors SHOULD update the web application accordingly when notified of a change request from the user agent or assistive technology.

Conformance Checkers

@@ -507,10 +507,8 @@

Information for Authors

  • tablist

    • User agents that support WAI-ARIA expand the usage of host language mechanisms such as tabindex, focus, and blur to allow them on all [=elements=]. Where the host language supports it, authors MAY add any element such as a div, span, or img to the default tab order by setting tabindex="0". In addition, any item with tabindex equal to a negative integer is focusable via script or a mouse click, but is not part of the default tab order. This is supported in both [[HTML]] and [[SVG2]].

    -

    - Authors MAY use aria-activedescendant to inform assistive technologies which descendant of a widget element is treated as having keyboard focus in the user interface if the role of the widget element supports aria-activedescendant. - This is often a more convenient way of providing keyboard navigation within widgets, such as a listbox, where the widget occupies only one stop in the page Tab sequence and other keys, typically arrow keys, are used to focus elements inside the widget. -

    +

    Authors MAY use aria-activedescendant to inform assistive technologies which descendant of a widget element is treated as having keyboard focus in the user interface if the role of the widget element supports aria-activedescendant. + This is often a more convenient way of providing keyboard navigation within widgets, such as a listbox, where the widget occupies only one stop in the page Tab sequence and other keys, typically arrow keys, are used to focus elements inside the widget.

    Typically, the author will use host language semantics to put the widget in the Tab sequence (e.g., tabindex="0" in HTML) and aria-activedescendant to point to the ID of the currently active descendant. The author, not the user agent, is responsible for styling the currently active descendant to show it has keyboard focus. The author cannot use :focus to style the currently active descendant since the actual focus is on the container.

    More information on managing focus can be found in the Developing a Keyboard Interface section of the WAI-ARIA Authoring Practices.

    @@ -583,7 +581,7 @@

    Abstract Roles

    Values
    Boolean
    -

    Abstract roles are the foundation upon which all other WAI-ARIA roles are built. Content authors MUST NOT use abstract roles because they are not implemented in the API binding. User agents MUST NOT map abstract roles to the standard role mechanism of the accessibility API. Abstract roles are provided to help with the following:

    +

    Abstract roles are the foundation upon which all other WAI-ARIA roles are built. Authors MUST NOT use abstract roles because they are not implemented in the API binding. User agents MUST NOT map abstract roles to the standard role mechanism of the accessibility API. Abstract roles are provided to help with the following:

    1. Organize the Roles Model and provide roles with a meaning in the context of known concepts.
    2. Streamline the addition of roles that include necessary features.
      3. @@ -591,13 +589,13 @@

      Abstract Roles

    Required States and Properties

    -

    States and [=ARIA/properties=] specifically required for the role and subclass roles. Content authors MUST provide a non-empty value for required states and properties. Content authors MUST NOT use the value undefined for required states and properties, unless undefined is an explicitly-supported value of that state or property.

    +

    States and [=ARIA/properties=] specifically required for the role and subclass roles. Authors MUST provide a non-empty value for required states and properties. Authors MUST NOT use the value undefined for required states and properties, unless undefined is an explicitly-supported value of that state or property.

    When an object inherits from multiple ancestors and one ancestor indicates that property is supported while another ancestor indicates that it is required, the property is required in the inheriting object.

    A host language attribute with the appropriate implicit WAI-ARIA semantic fulfills this requirement.

    Supported States and Properties

    -

    States and [=ARIA/properties=] specifically applicable to the role and child roles. Content authors MAY provide values for supported states and properties, but need not in cases where default values are sufficient. [=user agents=] MUST map all supported states and properties for the role to an accessibility API. If the state or property is undefined and it has a default value for the role, [=user agents=] SHOULD expose the default value.

    +

    States and [=ARIA/properties=] specifically applicable to the role and child roles. Authors MAY provide values for supported states and properties, but need not in cases where default values are sufficient. [=user agents=] MUST map all supported states and properties for the role to an accessibility API. If the state or property is undefined and it has a default value for the role, [=user agents=] SHOULD expose the default value.

    A host language attribute with the appropriate implicit WAI-ARIA semantic fulfills this requirement.

    @@ -973,7 +971,7 @@

    Definition of Roles

    alertdialog

    A type of dialog that contains an alert message, where initial focus goes to an element within the dialog. See related alert and dialog.

    -

    Alert dialogs are used to convey messages to alert the user. The alertdialog role goes on the [=nodes|node=] containing both the alert message and the rest of the dialog. Content authors SHOULD make alert dialogs modal by ensuring that, while the alertdialog is shown, keyboard and mouse interactions only operate within the dialog. See aria-modal.

    +

    Alert dialogs are used to convey messages to alert the user. The alertdialog role goes on the [=nodes|node=] containing both the alert message and the rest of the dialog. Authors SHOULD make alert dialogs modal by ensuring that, while the alertdialog is shown, keyboard and mouse interactions only operate within the dialog. See aria-modal.

    Unlike alert, alertdialog can receive a response from the user. For example, to confirm that the user understands the alert being generated. When the alert dialog is displayed, authors SHOULD set focus to an active element within the alert dialog, such as a form control or confirmation button. The user agent SHOULD fire a system alert event through the accessibility API when the alert is created, provided one is specified by the intended accessibility API.

    Authors SHOULD use aria-describedby on an alertdialog to reference the alert message element in the dialog. If they do not, an assistive technology can resort to its internal recovery mechanism to determine the contents of the alert message.

    @@ -3125,7 +3123,7 @@

    Definition of Roles

    When an assistive technology reading cursor moves from one article to another, assistive technologies SHOULD set user agent focus on the article that contains the reading cursor. If the reading cursor lands on a focusable element inside the article, the assistive technology MAY set focus on that element in lieu of setting focus on the containing article.

    Because the ability to scroll to another article with an assistive technology reading cursor depends on the presence of another article in the page, authors SHOULD attempt to load additional articles before user agent focus reaches an article at either end of the set of articles that has been loaded. Alternatively, authors MAY include an article at either or both ends of the loaded set of articles that includes an element, such as a button, that lets the user request more articles to be loaded.

    In addition to providing a brief label, authors MAY apply aria-describedby to article elements in a feed to suggest to screen readers which elements to speak after the label when users navigate by article. Screen readers MAY provide users with a way to quickly scan feed content by speaking both the label and accessible description when navigating by article, enabling the user to ignore repetitive or less important elements, such as embedded interaction widgets, that the author has left out of the description.

    -

    Authors SHOULD provide keyboard commands for moving focus among articles in a feed so users who do not utilize an assistive technology that provides article navigation features can use the keyboard to navigate the feed.

    +

    Authors SHOULD provide keyboard commands for moving focus among articles in a feed so users who do not utilize an assistive technology that provides article navigation features can use the keyboard to navigate the feed.

    If the number of articles available in a feed supply is static, authors MAY specify aria-setsize on article elements in that feed. However, if the total number is extremely large, indefinite, or changes often, authors MAY set aria-setsize to -1 to communicate the unknown size of the set.

    See the ARIA Authoring Practices Guide for additional details on implementing a feed design pattern.

    @@ -4184,7 +4182,7 @@

    Definition of Roles

    link

    An interactive reference to an internal or external resource that, when activated, causes the user agent to navigate to that resource. See related button.

    -

    If this is a native link in the host language (such as an HTML anchor with an href value), activating the link causes the user agent to navigate to that resource. If this is a simulated link, the web application author is responsible for managing navigation.

    +

    If this is a native link in the host language (such as an HTML anchor with an href value), activating the link causes the user agent to navigate to that resource. If this is a simulated link, the author is responsible for managing navigation.

    If pressing the link triggers an action but does not change browser focus or page location, authors are advised to consider using the button role instead of the link role.

    @@ -9987,7 +9985,7 @@
    Presentational Role Inheritance

    Supported States and Properties

    Clarification of States versus Properties

    -

    The terms "states" and "properties" refer to similar features. Both provide specific information about an object, and both form part of the definition of the nature of roles. In this document, states and properties are both treated as aria-prefixed markup [=attributes=]. However, they are maintained conceptually distinct to clarify subtle differences in their meaning. One major difference is that the values of properties (such as aria-labelledby) are often less likely to change throughout the application life-cycle than the values of states (such as aria-checked) which might change frequently due to user interaction. Note that the frequency of change difference is not a rule; a few properties, such as aria-valuetext are expected to change often. Because the distinction between states and properties is of little consequence to most web content authors, this specification refers to both "states" and "properties" simply as "attributes" whenever possible. See the definitions of state and property for more information.

    +

    The terms "states" and "properties" refer to similar features. Both provide specific information about an object, and both form part of the definition of the nature of roles. In this document, states and properties are both treated as aria-prefixed markup [=attributes=]. However, they are maintained conceptually distinct to clarify subtle differences in their meaning. One major difference is that the values of properties (such as aria-labelledby) are often less likely to change throughout the application life-cycle than the values of states (such as aria-checked) which might change frequently due to user interaction. Note that the frequency of change difference is not a rule; a few properties, such as aria-valuetext are expected to change often. Because the distinction between states and properties is of little consequence to most authors, this specification refers to both "states" and "properties" simply as "attributes" whenever possible. See the definitions of state and property for more information.

    Characteristics of States and Properties

    @@ -10242,14 +10240,14 @@

    State change notification

    Definitions of States and Properties (all aria-* attributes)

    -

    Below is an alphabetical list of WAI-ARIA states and [=ARIA/properties=] to be used by rich internet application authors. A detailed definition of each WAI-ARIA state and [=ARIA/property=] follows this compact list.

    +

    Below is an alphabetical list of WAI-ARIA states and [=ARIA/properties=] to be used by authors. A detailed definition of each WAI-ARIA state and [=ARIA/property=] follows this compact list.

    Placeholder for index of states and properties

    aria-activedescendant

    Identifies the currently active element when DOM focus is on a composite widget, combobox, textbox, group, or application.

    The aria-activedescendant property provides an alternative method of managing focus for interactive elements that might contain multiple focusable descendants, such as menus, grids, and toolbars. Instead of moving DOM focus among accessibility descendants, authors MAY set DOM focus on a container element that supports aria-activedescendant and then use aria-activedescendant to refer to the element that is active.

    -

    Authors MUST ensure that one of the following two sets of conditions is met when setting the value of aria-activedescendant on an element with DOM focus:

    +

    Authors MUST ensure that one of the following two sets of conditions is met when setting the value of aria-activedescendant on an element with DOM focus:

    1. The value of aria-activedescendant refers to an accessibility descendant.
    2. @@ -10257,7 +10255,7 @@

      Definitions of States and Properties (all aria-* attributes)

      For example, in a combobox, focus can remain on the combobox while the value of aria-activedescendant on the combobox element refers to a descendant of a popup listbox that is controlled by the combobox.
    -

    Authors SHOULD also ensure that the currently active descendant is visible and in view (or scrolls into view) when focused.

    +

    Authors SHOULD also ensure that the currently active descendant is visible and in view (or scrolls into view) when focused.

    @@ -10436,7 +10434,7 @@

    Definitions of States and Properties (all aria-* attributes)

  • The value of aria-braillelabel is not identical to the element's accessible name.

    • Authors MUST NOT specify aria-braillelabel on an element which has an explicit or implicit WAI-ARIA role where aria-braillelabel is prohibited.

    -

    Note that Assistive Technologies with braille support can convert the accessible name to Braille. In addition, assistive technologies will be able to customize such braille output according to user preferences. Using only the accessible name, e.g., from content or via aria-label is almost always the better user experience and authors are strongly discouraged from using aria-braillelabel to replicate aria-label. Instead, aria-braillelabel is meant to be used only if the accessible name cannot provide an adequate braille representation, i.e., when a specialized braille description is very different from a text description converted to Braille. It is very important to note that when using aria-braillelabel authors are solely responsible for localizing the attribute value so that it aligns with the document language. In addition, authors need to design a way to clearly communicate the use of this attribute to the user. For example, this could be done in the product documentation. This is even more important when the value consists of Unicode Braille Patterns because Assistive Technologies will pass such content directly to the user without applying user specific braille translations; in general, authors are strongly discouraged from using Unicode Braille Patterns in aria-braillelabel. +

    Note that Assistive Technologies with braille support can convert the accessible name to Braille. In addition, assistive technologies will be able to customize such braille output according to user preferences. Using only the accessible name, e.g., from content or via aria-label is almost always the better user experience and authors are strongly discouraged from using aria-braillelabel to replicate aria-label. Instead, aria-braillelabel is meant to be used only if the accessible name cannot provide an adequate braille representation, i.e., when a specialized braille description is very different from a text description converted to Braille. It is very important to note that when using aria-braillelabel, authors are solely responsible for localizing the attribute value so that it aligns with the document language. In addition, authors need to design a way to clearly communicate the use of this attribute to the user. For example, this could be done in the product documentation. This is even more important when the value consists of Unicode Braille Patterns because Assistive Technologies will pass such content directly to the user without applying user specific braille translations; in general, authors are strongly discouraged from using Unicode Braille Patterns in aria-braillelabel.

    Assistive technologies SHOULD use the value of aria-braillelabel when presenting the accessible name of an element in Braille, but SHOULD NOT change other functionality. For example, an assistive technology that provides aural rendering SHOULD use the accessible name.

    Assistive technologies SHOULD expose the aria-braillelabel property as follows:

    @@ -10488,7 +10486,7 @@

    Definitions of States and Properties (all aria-* attributes)

  • The value of aria-brailleroledescription does not contain any characters in Unicode Braille Patterns or consists of only characters in Unicode Braille Patterns; the value does not only contain Braille Pattern dots-0.
  • The value of aria-brailleroledescription should not be identical to the element's WAI-ARIA aria-roledescription, WAI-ARIA role or implicit WAI-ARIA role semantic.
    • -

    Note that Assistive Technologies with braille support can convert aria-roledescription content to Braille. In addition, assistive technologies will be able to customize such braille output according to user preferences. Using only aria-roledescription is almost always the better user experience and authors are strongly discouraged from using aria-brailleroledescription to replicate aria-roledescription. Instead, aria-brailleroledescription is meant to be used only when aria-roledescription cannot provide an adequate braille representation, i.e., when a specialized braille description is very different from a text description converted to Braille. It is very important to note that when using aria-brailleroledescription authors are solely responsible for localizing the attribute value so that it aligns with the document language. In addition, authors need to design a way to clearly communicate the use of this attribute to the user. For example, this could be done in the product documentation. This is even more important when the value consists of Unicode Braille Patterns because Assistive Technologies will pass such content directly to the user without applying user specific braille translations; in general, authors are strongly discouraged from using Unicode Braille Patterns in aria-brailleroledescription. +

    Note that Assistive Technologies with braille support can convert aria-roledescription content to Braille. In addition, assistive technologies will be able to customize such braille output according to user preferences. Using only aria-roledescription is almost always the better user experience and authors are strongly discouraged from using aria-brailleroledescription to replicate aria-roledescription. Instead, aria-brailleroledescription is meant to be used only when aria-roledescription cannot provide an adequate braille representation, i.e., when a specialized braille description is very different from a text description converted to Braille. It is very important to note that when using aria-brailleroledescription, authors are solely responsible for localizing the attribute value so that it aligns with the document language. In addition, authors need to design a way to clearly communicate the use of this attribute to the user. For example, this could be done in the product documentation. This is even more important when the value consists of Unicode Braille Patterns because Assistive Technologies will pass such content directly to the user without applying user specific braille translations; in general, authors are strongly discouraged from using Unicode Braille Patterns in aria-brailleroledescription.

    User agents MUST NOT expose the aria-brailleroledescription property if any of the following conditions exist:

      @@ -11665,7 +11663,7 @@

      Definitions of States and Properties (all aria-* attributes)

      aria-invalid

      Indicates the entered value does not conform to the format expected by the application. See related aria-errormessage.

      -

      If the value is computed to be invalid or out-of-range, the application author SHOULD set this attribute to true. [=user agents=] SHOULD inform the user of the error. Application authors SHOULD provide suggestions for corrections if they are known.

      +

      If the value is computed to be invalid or out-of-range, the author SHOULD set this attribute to true. [=user agents=] SHOULD inform the user of the error. Authors SHOULD provide suggestions for corrections if they are known.

      When the user attempts to submit data involving a field for which aria-required is true, authors MAY use the aria-invalid attribute to signal there is an error. However, if the user has not attempted to submit the form, authors SHOULD NOT set the aria-invalid attribute on required widgets simply because the user has not yet entered data.

      For future expansion, the aria-invalid attribute is a token type. Any value not recognized in the list of allowed values MUST be treated by user agents as if the value true had been provided. If the attribute is not present, or its value is false, or its value is the empty string, the default value of false applies.

      This state is being deprecated as a global state in ARIA 1.2. In future versions it will only be allowed on roles where it is specifically supported.

      @@ -12369,7 +12367,7 @@

      Definitions of States and Properties (all aria-* attributes)

      aria-readonly

      Indicates that the element is not editable, but is otherwise operable. See related aria-disabled.

      -

      This means the user can read but not set the value of the widget. Readonly elements are relevant to the user, and application authors SHOULD NOT restrict navigation to the element or its focusable descendants. Other actions such as copying the value of the element are also supported. This is in contrast to disabled elements, to which applications might not allow user navigation to descendants.

      +

      This means the user can read but not set the value of the widget. Readonly elements are relevant to the user, and authors SHOULD NOT restrict navigation to the element or its focusable descendants. Other actions such as copying the value of the element are also supported. This is in contrast to disabled elements, to which applications might not allow user navigation to descendants.

      Examples include:

      • A form element which represents a constant.
        • @@ -13324,7 +13322,7 @@

        State and Property Attributes

        Focus Navigation

        -

        An implementing host language MUST provide support for the author to make all interactive elements focusable, that is, any renderable or event-receiving elements. An implementing host language MUST provide a facility to allow web authors to define whether these focusable, interactive elements appear in the default tab navigation order. The tabindex attribute in HTML is an example of one implementation.

        +

        An implementing host language MUST provide support for the author to make all interactive elements focusable, that is, any renderable or event-receiving elements. An implementing host language MUST provide a facility to allow authors to define whether these focusable, interactive elements appear in the default tab navigation order. The tabindex attribute in HTML is an example of one implementation.

        Implicit WAI-ARIA Semantics

        @@ -13372,7 +13370,7 @@

        State and Property Attribute Processing

        ID Reference Error Processing

        [=user agents=] SHOULD ignore ID references that do not match the ID of another element in the same document.

        -

        It is the web author's responsibility to ensure that IDs are unique. If more than one element has the same ID, the user agent SHOULD use the first element found with the given ID. The behavior will be the same as getElementById.

        +

        It is the author's responsibility to ensure that IDs are unique. If more than one element has the same ID, the user agent SHOULD use the first element found with the given ID. The behavior will be the same as getElementById.

        If the same element is specified multiple times in a single WAI-ARIA relation, user agents SHOULD return multiple pointers to the same element.

        aria-activedescendant is defined as referencing only a single ID reference. Any aria-activedescendant value that does not match an existing ID reference exactly is an author error and will not match any element in the DOM.

    Characteristics: