W3C home > Mailing lists > Public > public-aria@w3.org > May 2016

RE: Meaning of strong

From: Birkir Gunnarsson <birkir.gunnarsson@deque.com>
Date: Thu, 12 May 2016 17:08:33 -0400
To: "'Bryan Garaventa'" <bryan.garaventa@ssbbartgroup.com>, "'Matt King'" <a11ythinker@gmail.com>, "'ARIA Working Group'" <public-aria@w3.org>
Message-ID: <025001d1ac92$71eb3e20$55c1ba60$@deque.com>
I have frequently seen role="heading" used on an interactive element (I
often see this in webpage responsive modes).

I have been looking for W3C or WCAG text to fail this using automated
checks, and have yet to come up with a reliable strategy.

All of Bryan's examples are good.

Also any time an interactive widget is mapped to a static ARIA role and when
an interactive role such as button is used on elements inside another
interactive element (such as a link) (I have seen that construct on client
webpages). 

<a href="#"><span role="button">something</span> some text</a>

 

From: Bryan Garaventa [mailto:bryan.garaventa@ssbbartgroup.com] 
Sent: Thursday, May 12, 2016 3:44 PM
To: Matt King <a11ythinker@gmail.com>; ARIA Working Group
<public-aria@w3.org>
Subject: RE: Meaning of strong 

 

Here are a few bad examples of this that I've seen recently with some
clients.

 

<input type="text" title="Username" role="menuitem" >

 

And

 

<select role="listbox" multiselect >

<option role="checkbox" >Item One</option>

</select>

 

Plus others like

 

<input type="checkbox" role="button" >

 

Give me a few minutes more and I can come up with many more that I've seen.

 

Bryan Garaventa

Accessibility Fellow

SSB BART Group, Inc.

bryan.garaventa@ssbbartgroup.com <mailto:bryan.garaventa@ssbbartgroup.com> 

415.624.2709 (o)

www.SSBBartGroup.com <http://www.SSBBartGroup.com> 

 

From: Matt King [mailto:a11ythinker@gmail.com] 
Sent: Thursday, May 12, 2016 12:09 PM
To: ARIA Working Group <public-aria@w3.org <mailto:public-aria@w3.org> >
Subject: Meaning of strong 

 

As a result of action 1489, I am taking a close look at the text of section
7.5:

https://rawgit.com/w3c/aria/ACTION-1489/aria/aria.html#host_general_conflict

 

My first set of questions from this section are about this paragraph
describing strong native semantics.

 

"Host languages may document features that cannot be overridden with
WAI-ARIA (these are called "strong native semantics"). These can be features
that have implicit WAI-ARIA semantics, as well as features where the
processing would be uncertain if the semantics were changed with WAI-ARIA.
Conformance checkers may signal an error or warning when a WAI-ARIA role is
used on elements with strong native semantics, but as described above, user
agents must still use the value of the semantic of the WAI-ARIA role when
exposing the element to accessibility APIs."

 

If I understand this paragraph, in the event that an author specifies an
ARIA role for an HTML element that has strong native semantics, a
conformance checker may call out an error. However, a browser must ignore
theHTML semantics and use the ARIA semantics.

 

Questions:

1.       Is my understanding correct?

2.       If the browser must respect the ARIA, isn't the first sentence
incorrect where it uses the word "cannot". Shouldn't "cannot" be replaced
with "should not"? 

3.       What is an example? Could we include one in the text?

4.       Why do we call this "strong" native semantics if they have no
effect on the way user agents and assistive technologies behave? What is
"strong" about this? It seems more like they are "preferred" native
semantics.

 

Matt King
Received on Thursday, 12 May 2016 21:09:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:58:26 UTC