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

Matt,

I’d like to comment on some points.

First, I think James Craig brought up the idea having an extra “text” role to indicate *semantic content composed of text*, not to state the obvious.

Again, I second that idea. But not the wording of the role name.
For me the name should be something better expressing this good idea.

It should be more designated / specific,  e.g. role=”graphictext” and can be used in context like

<span role=”graphictext” aria-label=”Critical”  style=”color:red”>Out of Stock</span>

In an ideal world, Jaws should


1.       Not overridde the content of inner text node because aria-label is set

2.       Detect that this is not plain text but text with additional semantic meaning because of role=” graphictext”

3.       Speak “Out of Stock – Critical”

And yes I know that there are other (and often inappropriate) techniques to do that, but we are talking about ARIA 1.1 and a better future.

>>> aria-label on a span would "supplement" the content of the span, not replace it.

Actually, the implementations of this I tested with Jaws and IE differ considerably from this – they really replace test node content.

>>> I can not find anything in the spec that says what should be done with an aria-label on a paragraph.

Exactly. For the sake of completeness, same hold true for aria-labelledby and describedby. It is simply not defined that NOTHING should be done with – but the opposite is also the case.

>>> are examples  of roles where the spec is clear …,  experienced its unintended consequences to devistating effect at times.

This is exactly the reason why I suggested an additional role assignment necessary – to avoid strange effects.

Best Regards
Stefan

From: Matthew King [mailto:mattking@us.ibm.com]
Sent: Mittwoch, 12. November 2014 11:50
To: Marco Zehe
Cc: Cynthia Shelly; Steve Faulkner; Fred Esch; James Craig; Joanmarie Diggs; White, Jason J; lisa.seeman; W3C WAI Protocols & Formats; Schnabel, Stefan
Subject: 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<mailto:mattking@us.ibm.com>



From:        Marco Zehe <mzehe@mozilla.com<mailto:mzehe@mozilla.com>>
To:        "Schnabel, Stefan" <stefan.schnabel@sap.com<mailto:stefan.schnabel@sap.com>>, "lisa.seeman" <lisa.seeman@zoho.com<mailto:lisa.seeman@zoho.com>>, James Craig <jcraig@apple.com<mailto:jcraig@apple.com>>,
Cc:        Cynthia Shelly <cyns@microsoft.com<mailto:cyns@microsoft.com>>, "White, Jason J" <jjwhite@ets.org<mailto:jjwhite@ets.org>>, Fred Esch/Arlington/IBM@IBMUS, Matthew King/Fishkill/IBM@IBMUS, Steve Faulkner <faulkner.steve@gmail.com<mailto:faulkner.steve@gmail.com>>, Joanmarie Diggs <jdiggs@igalia.com<mailto:jdiggs@igalia.com>>, W3C WAI Protocols & Formats <public-pfwg@w3.org<mailto: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 <http://accessibility.athena-ict.com/>
LinkedIn<http://il.linkedin.com/in/lisaseeman/>, Twitter<https://twitter.com/SeemanLisa>




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

> On Nov 11, 2014, at 5:41 PM, Cynthia Shelly <cyns@microsoft.com<mailto: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