Warning:
This wiki has been archived and is now read-only.

ChangeProposals/ARIAonanchor

From HTML WG Wiki
Jump to: navigation, search

Allow the a element to have ARIA role attribute values other than link

Editor: Steve Faulkner (faulkner.steve@gmail.com)

Date: February 26, 2010.

Please address feedback to the HTML Working Group mailing list (public-html@w3.org).

Resolves ISSUE-85.

Summary

Allow the a element to have a role attribute with values other than role="link".

Rationale

Currently the a element is defined in the HTML5 specification as an element that cannot have its native role overriden by ARIA roles. Developers have and will most probably continue to repurpose the a element to achieve desired interface features and style considerations using Javascript and CSS. While re-purposing the element may be non-conforming in HTML5, there is no indication to developers when using a conformance checker, because the changes that are made to make it non conforming cannot be checked using an automated conformance tool. So there is no reason to believe that as long as developers find a reason to repurpose the a element they will stop doing because it says so in the HTML specification. This view is confirmed by the author of the current ARIA in HTML5 conformance requirements:

"@cwilso I think we both know Web developers aren't going to be using the specs as a guide of what they can and can't use"

The use of ARIA in this case provides a way for developers to provide the same information about a custom control they have developed using the a element to assistive technology AT users that is available to everyone else.

Flagging the use of ARIA as a conformance error will most likely deter those people using conformance checkers from adding the ARIA attributes, while leaving an inaccessible control. The only people disadvantaged by the conformance requirements in the current spec are users with disabilities.

In some cases the addition of ARIA attributes, along with scripted behaviour and styling to elements when Javascript is supported, allows for graceful degredation of the content for when Javascript is not supported. This is an approach that should be encouraged not prohibited.

Examples of the a element being repurposed in popular JavaScript UI libraries:

Examples:

Details

Remove the first row of the first table in the section 3.2.6 Annotations for assistive technology products (ARIA).

code/content to be removed:

<tr><td><a href="text-level-semantics.html#the-a-element">a</a> element that represents a <a href="interactive-elements.html#hyperlink">hyperlink</a></td><td>link role</td></tr>

Add this as the first row of the second table in the section 3.2.6 Annotations for assistive technology products (ARIA).

code/content to be added:

<tr> <td><a href="text-level-semantics.html#the-a-element">a</a> element that represents a <a href="interactive-elements.html#hyperlink">hyperlink</a></td> <td> link role</td> <td>If specified, role may be one of the following button, link, menuitem, menuitemcheckbox, menuitemradio, radio, slider, scrollbar or progressbar.</td> </tr>

Impact

Positive Effects

  • Authors will not be detered (by conformance error messages) from using ARIA to provide name, role and state information to AT users that matches the information provided to other users.
  • Developers will be able to use conformance checkers to check their code for correct syntax,values combinations etc of ARIA attributes providing an indication of whether they will actually work as per the ARIA spec, rather than to be told whether their use is prohibited by the HTML5 spec or not.
  • HTML5 author conformance requirements will better reflect the real world uses of the a element.

Negative Effects

  • Will no longer provide an indirect mechansim for automated conformance checkers to flag potential non-conforming uses of the a element, which would otherwise be uncheckable.

Conformance Classes Changes

?

Risks

refer to negative effects.

References