Re: First draft of ARIA 1.1. "text" role

Marco, aria-labelledby or aria-label only takes the place of the contents 
of an element if the role specifies that accessible name is from contents.
In the definition of role presentation, it is clear that span is redundant 
with or equivalent to presentation.
Role presentation specifies that the accessible name comes from author.
So, based on this, aria-label on a span would "supplement" the content of 
the span, not replace it.

The spec is silent about elements that don't have an implied aria role, 
for example paragraph. I can not find anything in the spec that says what 
should be done with an aria-label on a paragraph. There is probably some 
phrase buried in there someplace that covers it.

On the other hand, consider list item, heading, button, and link. These 
are examples  of roles where the spec is clear that aria-label would 
replace the content.
This is a sometimes useful but nonetheless dangerous aspect of ARIA, and I 
have, like probably most of us screen reader users,  experienced its 
unintended consequences to devistating effect at times.

Matt King
IBM Senior Technical Staff Member
I/T Chief Accessibility Strategist
IBM BT/CIO - Global Workforce and Web Process Enablement 
Phone: (503) 578-2329, Tie line: 731-7398
mattking@us.ibm.com



From:   Marco Zehe <mzehe@mozilla.com>
To:     "Schnabel, Stefan" <stefan.schnabel@sap.com>, "lisa.seeman" 
<lisa.seeman@zoho.com>, James Craig <jcraig@apple.com>, 
Cc:     Cynthia Shelly <cyns@microsoft.com>, "White, Jason J" 
<jjwhite@ets.org>, Fred Esch/Arlington/IBM@IBMUS, Matthew 
King/Fishkill/IBM@IBMUS, Steve Faulkner <faulkner.steve@gmail.com>, 
Joanmarie Diggs <jdiggs@igalia.com>, W3C WAI Protocols & Formats 
<public-pfwg@w3.org>
Date:   11/12/2014 01:52 AM
Subject:        Re: First draft of ARIA 1.1. "text" role



Well if I remember correctly, it has always been said that if something 
has an aria-label* construct, it should be prioritized over any normal 
text that might also be there. If some AT vendors don't honor that, or 
only honor it if some random selection tells it to, that's not a problem 
of the ARIA spec and doesn't need an extra role. If an extra would be what 
is needed to make it more palpable to somebody, then we do have a problem, 
but not a technical one, but an evangelism one. Because, turning things on 
its head, a role does not necessitate an aria-label* construct. In other 
words, an aria-label* construct can exist without a role, and should be 
treated by ATs accordingly. Likewise, the presence of a role does not mean 
there always has to be an aria-label* construct, and ATs should not stop 
looking for other means of a name just because there is a role set.

If we suddenly started to require a role always be present if an 
aria-label* construct is, and vice versa, it defeats the premise that ARIA 
is an addition where the host language falls short. Because if the host 
language already provides the correct semantics for a role, which it does 
in your example, or for a given widget role, the mechanics of the host 
language provide the correct name already, there is no need to use the 
other respectively. It would only over-complicate things unnecessarily and 
lead to code that is bigger than it needs to be.

And, as Lisa pointed out already, things should not become more 
complicated for the average web developer and consultant as it already is. 
You, Stefan, will probably get it right if we did this, I would, too, and 
presumably everybody else on this list. But the potential for mis-use of 
even more roles and stuff is so big that I am really scared. In my 
opinion, this has the potential to be misused just as much as role 
"application".

Marco

On 12.11.2014 10:38, Schnabel, Stefan wrote:
Hi Marco,
 
because (as I have written) from an implementers viewpoint, adding a 
“trigger“ or a member in the list of
roles where ARIA labelling has to be supported (which is what they 
actually do for some but not all roles) is maybe on a higher acceptance 
level.
 
However,
 
<span role=”application” aria-label=”Out of stock – That is  Critical” 
style=”color:red”>Out of Stock</span>
 
will work already, too, but role=application will be likely deprecated in 
ARIA 1.1.
 
Regarding your last post: Applause for the FF / NVDA support of this but I 
do not see any contradiction in emphasizing by role that something is more 
than just plain text. 
 
Best Regards + Troll Greetings
Stefan
 
 
From: Marco Zehe [mailto:mzehe@mozilla.com] 
Sent: Mittwoch, 12. November 2014 10:28
To: Schnabel, Stefan; lisa.seeman; James Craig
Cc: Cynthia Shelly; White, Jason J; Fred Esch; Matthew King; Steve 
Faulkner; Joanmarie Diggs; W3C WAI Protocols & Formats
Subject: Re: First draft of ARIA 1.1. "text" role
 
Hi Stefan,

OK, trolling back:
What makes you think they'll support role="text" if they don't get aria 
labelling right now?

Marco
On 12.11.2014 10:04, Schnabel, Stefan wrote:
Hi Marco,
 
I’m in the mood for some trolling since I don’t understand sometimes 
implementation logic behind.
 
Can you please go ahead and tell FS that they should support aria-label 
(or labelledby, describedby) e.g. in
 
<span aria-label=”Out of stock – That is  Critical” style=”color:red”>Out 
of Stock</span>
 
in ALL their modes (important!) according to the ARIA spec WITHOUT having 
a role applied on the span or on the body?
 
If they refuse, having
 
<span role=”text” aria-label=”Out of stock – That is  Critical” 
style=”color:red”>Out of Stock</span>
 
will make things clearer for the screen readers that there is more than 
just plain text .. namely ARIA-attributed text.
 
Best Regards
Stefan
 
From: Marco Zehe [mailto:mzehe@mozilla.com] 
Sent: Mittwoch, 12. November 2014 09:24
To: lisa.seeman; James Craig
Cc: Cynthia Shelly; White, Jason J; Fred Esch; Matthew King; Steve 
Faulkner; Joanmarie Diggs; W3C WAI Protocols & Formats
Subject: Re: First draft of ARIA 1.1. "text" role
 
+1000 to that, Lisa! Given the history of the web, I think it is safe to 
assume that everything that is nothing else is text, and that text does 
not need its own role. None of the examples I have seen in this thread 
convinced me that this is either necessary nor in any way helpful.

Marco


On 12.11.2014 07:48, lisa.seeman wrote:
My 2 cents 
Each new role we introduce will create a learning curve for authors, many 
of whom will initially apply it incorrectly, killing the user experience, 
until an accessibility consultant tells them how to use it correctly. 
(Assuming the consultant is not also using it inappropriately - this is 
not to be taken for a given.) I say this based on a lot of personal 
experience.
 
If we do not need a new role we should not create it.
 
 
All the best

Lisa Seeman

Athena ICT Accessibility Projects 
LinkedIn, Twitter


 

---- On Wed, 12 Nov 2014 05:15:29 +0200 James Craig<jcraig@apple.com> 
wrote ---- 

> On Nov 11, 2014, at 5:41 PM, Cynthia Shelly <cyns@microsoft.com> wrote: 
> 
> I wonder if it might make more sense to change the definition of 
presentation or none to cover this scenario 
> 
> <p>I <img src="heart.gif" alt="love" role="none"> New York.</p> 
> 
> to read "I love New York" instead of "I New York" 

As Matt alluded, the ARIA 1.0 "presentation" role ("none" is a 1.1 synonym 
role of "presentation") does not expose any attribute or role semantics, 
so this would not expose the text alternative. 

> The glyph scenario is different, because it is text, and is often read 
as a single character. 

I don't think it'd always be limited to a single character. 

> But, do we need a role for that? Would this work instead? 
> 
> <p>I <span aria-label="love">♥</span> New York.</p> 

The role of the span is ambiguous here. Some platforms don't expose the 
span at all, preferring to flatten the selection string, so there is no 
element on which to hang the label. (Though that might just be an 
implementation detail.) 

James