E-mail List Archives

You are here: Home > Community > E-mail List Archives > View Thread

Thread: Changing semantics via ARIA Role

Number of posts in this thread: 4 (In chronological order)

From: Dennis Deacon
Date: Tue, Sep 15 2015 9:30AM
Subject: Changing semantics via ARIA Role
No previous message | Next message →

I understand that changing an element's role is generally frowned upon. An
example would be placing role="link" on a div (just use a link). Are there
acceptable exceptions to this (say role="button" on a link)?

I ask because general guidance seems to bend on this inferred hard & fast
rule.

Thanks in advance.

--
Dennis Deacon
Email: = EMAIL ADDRESS REMOVED =
Website/Portfolio: dennisdeacon.com
Blog: dennisdeacon.com/blog
LinkedIn Profile: linkedin.com/in/dennisdeacon

From: Joseph Sherman
Date: Tue, Sep 15 2015 10:00AM
Subject: Re: Changing semantics via ARIA Role
← Previous message | Next message →

This Working Draft specification<http://www.w3.org/TR/html-aria/>; defines the web developer rules (author conformance requirements) for the use of [wai-aria-1.1] attributes on [HTML51] elements. It also defines requirements for Conformance Checking tools.

Web developers MAY use the ARIA role and aria-* attributes on HTML elements<http://www.w3.org/TR/html/index.html#elements-1>;, in accordance with the requirements described in [wai-aria-1.1<http://www.w3.org/TR/html-aria/#bib-wai-aria-1.1>;], except where these conflict with the strong native semantics<http://www.w3.org/TR/html/infrastructure.html#strong-native-semantics>; or are equal to the default implicit ARIA semantics<http://www.w3.org/TR/html/infrastructure.html#default-implicit-aria-semantics>; of a given HTML element. These constraints, are intended to prevent developers from making assistive technology products report nonsensical user interface information (UI) that does not represent the actual UI of the document.

Web developers MUST NOT use the ARIA role and aria-* attributes in a manner that conflicts with the semantics described in the Document conformance requirements for use of ARIA attributes in HTML<http://www.w3.org/TR/html-aria/#docconformance>; table. Web developers SHOULD NOT set the ARIA role and aria-* attributes to values that match the default implicit ARIA semantics defined in the table.

http://www.w3.org/TR/html-aria/

Joseph Sherman
Accessibility Specialist
CUNY Computing & Information Services
395 Hudson St 6FL, 6-236
646-664-2167| = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >

-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Dennis Deacon
Sent: Tuesday, September 15, 2015 11:31 AM
To: = EMAIL ADDRESS REMOVED =
Subject: [WebAIM] Changing semantics via ARIA Role

I understand that changing an element's role is generally frowned upon. An example would be placing role="link" on a div (just use a link). Are there acceptable exceptions to this (say role="button" on a link)?

I ask because general guidance seems to bend on this inferred hard & fast rule.

Thanks in advance.

--

Dennis Deacon

Email: = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >

Website/Portfolio: dennisdeacon.com

Blog: dennisdeacon.com/blog

LinkedIn Profile: linkedin.com/in/dennisdeacon

From: Birkir R. Gunnarsson
Date: Tue, Sep 15 2015 11:20AM
Subject: Re: Changing semantics via ARIA Role
← Previous message | Next message →

The short answer:
If you make it look like a duck, it also has to quack like a duck,
feel like a duck and taste like a duck.
If you start with an anchor tag and slap role="button" on it, make
sure it looks like a button and can be activated with enter or space
bar (because that is how the button element works).
If you start with a div, you have to make it focusable, assign the
button role, assign an accessible name, make it look like a button,
make sure its click event is fired when user presses spacebar or
enter key etc.

If you do all of those things, you can use ARIA to create widgets.
If you tell the user you have a button, the user should never be able
to find out (without inspecting your code) that, in fact, it isn't.
-B

On 9/15/15, Joseph Sherman < = EMAIL ADDRESS REMOVED = > wrote:
> This Working Draft specification<http://www.w3.org/TR/html-aria/>; defines
> the web developer rules (author conformance requirements) for the use of
> [wai-aria-1.1] attributes on [HTML51] elements. It also defines requirements
> for Conformance Checking tools.
>
> Web developers MAY use the ARIA role and aria-* attributes on HTML
> elements<http://www.w3.org/TR/html/index.html#elements-1>;, in accordance
> with the requirements described in
> [wai-aria-1.1<http://www.w3.org/TR/html-aria/#bib-wai-aria-1.1>;], except
> where these conflict with the strong native
> semantics<http://www.w3.org/TR/html/infrastructure.html#strong-native-semantics>;
> or are equal to the default implicit ARIA
> semantics<http://www.w3.org/TR/html/infrastructure.html#default-implicit-aria-semantics>;
> of a given HTML element. These constraints, are intended to prevent
> developers from making assistive technology products report nonsensical user
> interface information (UI) that does not represent the actual UI of the
> document.
>
> Web developers MUST NOT use the ARIA role and aria-* attributes in a manner
> that conflicts with the semantics described in the Document conformance
> requirements for use of ARIA attributes in
> HTML<http://www.w3.org/TR/html-aria/#docconformance>; table. Web developers
> SHOULD NOT set the ARIA role and aria-* attributes to values that match the
> default implicit ARIA semantics defined in the table.
>
>
>
>
>
> http://www.w3.org/TR/html-aria/
>
>
>
>
>
> Joseph Sherman
> Accessibility Specialist
> CUNY Computing & Information Services
> 395 Hudson St 6FL, 6-236
> 646-664-2167| = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >
>
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Dennis Deacon
> Sent: Tuesday, September 15, 2015 11:31 AM
> To: = EMAIL ADDRESS REMOVED =
> Subject: [WebAIM] Changing semantics via ARIA Role
>
>
>
> I understand that changing an element's role is generally frowned upon. An
> example would be placing role="link" on a div (just use a link). Are there
> acceptable exceptions to this (say role="button" on a link)?
>
>
>
> I ask because general guidance seems to bend on this inferred hard & fast
> rule.
>
>
>
> Thanks in advance.
>
>
>
> --
>
> Dennis Deacon
>
> Email: = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >
>
> Website/Portfolio: dennisdeacon.com
>
> Blog: dennisdeacon.com/blog
>
> LinkedIn Profile: linkedin.com/in/dennisdeacon
>
> >
> > http://webaim.org/discussion/archives
>
> > = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >
> > > > >

--
Work hard. Have fun. Make history.

From: Léonie Watson
Date: Tue, Sep 15 2015 11:32AM
Subject: Re: Changing semantics via ARIA Role
← Previous message | No next message

> From: WebAIM-Forum on Behalf Of Dennis Deacon
> Sent: 15 September 2015 16:31
> I understand that changing an element's role is generally frowned upon. An
> example would be placing role="link" on a div (just use a link). Are there
> acceptable exceptions to this (say role="button" on a link)?

It's a judgement call based on the context.

The <div> and <span> elements are semantically neutral (they don't have meaningful default roles). It's often ok to explicitly apply another role to either element, but it comes at a cost. For example, if you apply role="link" to a <div>, you have to handle keyboard focus plus keyboard and mouse interaction through scripting. Even then, you lose some expected features of a standard link (like the default browser context menu).

It's when you override the semantics of other elements you really need to be cautious. It would make no sense to do something like the following for example:

<h1 role="button">This heading</h1>

That said, there are times when it is ok to override the native semantics of elements. If you use a <ul> and some <div> elements to create the basis of a set of tabs for example. Applying the tablist, tab and tabpanel roles actually provides more meaningful semantics than the original HTML elements do.

So being aware of whether the element has a strong role of it's own, and considering whether the role(s) you apply will provide more meaningful semantics or break something important, is the basic strategy.

Léonie.

--
Senior accessibility engineer @PacielloGroup @LeonieWatson