RE: Proposal and Justification for ARIA 1.2 (Was: text role removal)

James Craig wrote:

 

>Recommending they remove it now will break their current implementation. 

>They should not remove it until there is an suitable replacement, 

 

I don’t think anything would necessarily break. They would simply need to use an alternative ARIA markup, e.g., use the img role and an aria-label if it is a graphical element. That would be appropriate for the ratings widget, for example. The only thing that would change is that the element would be spoken by screen readers as an image or graphic instead of that semantic information being omitted from screen reader output.

 

>Are you really going to notify 600 sites? 

 

It appears that all of these organizations are following development of the ARIA standard or they wouldn’t have implemented something that is not yet baked into the standard and only supported by a limited set of browsers. So, it is probably not necessary to go beyond the normal communications regarding changes in the draft specification.

 

>Please don't alert the public that their "will be" a replacement until there is a spec to point them to.

 

Agree; we should not commit to a replacement until we have agreement on all the following:

1.     A clear definition of the problem being solved.

2.     There is need for a solution to that problem.

3.     The solution falls within the scope of ARIA.

 

Matt

 

From: James Craig [mailto:jcraig@apple.com] 
Sent: Wednesday, August 10, 2016 11:08 AM
To: Joanmarie Diggs <jdiggs@igalia.com>
Cc: Accessible Rich Internet Applications Working Group <public-aria@w3.org>; Steven Faulkner <faulkner.steve@gmail.com>; Richard Schwerdtfeger <richschwer@gmail.com>; Michiel Bijl <michiel@agosto.nl>
Subject: Re: Proposal and Justification for ARIA 1.2 (Was: text role removal)

 

 

On Aug 10, 2016, at 8:29 AM, Joanmarie Diggs <jdiggs@igalia.com <mailto:jdiggs@igalia.com> > wrote:

 

Hey James, all.

+1 to a small, focused ARIA 1.2 release
+1 to continuing to work towards a solution for text/static
-1 to adding a deprecated-but-valid synonym role called "text"

One of the biggest problems (in my mind) with the "text" rolename is
that it implies the element's contents will be turned into textual
content. That is NOT what it does. And I would argue it does the
complete opposite, with "untext" being a more accurate reflection of the
role's purpose for elements which lack an accessible name, and
"deletetext" for those elements which have an accessible name.

Beyond the above, adding a deprecated-from-the-start alias to a spec
strikes me as odd. Adding a deprecated-from-the-start
potentially-confusing alias to a spec strikes me as wrong. Sorry....

 

Certainly. It would have been more appropriate to include the replacement role name in 1.1 rather than removing it with no replacement, but that ship has sailed, too.

 

As a compromise, we could include a note that clarifies the following:

 

* ARIA 1.1 drafts had a "text" role that was used for a similar function.
* It was removed due to …
* It's likely to remain as an alias in WebKit (and possibly Blink) b/c removing it would break sites.
* It's okay for sites with existing use to use role="newname oldname" as a fallback to ensure ongoing support.





I think it's awesome that Simon did this research for us. Thank you for
asking him to. Let's notify the jQuery folks 

 

Recommending they remove it now will break their current implementation. They should not remove it until there is an suitable replacement, and then, they should use the existing as a fallback role: e.g. role="static text"... Once the new role name is in the spec, we can spread the word.





and Bed, Bath, and Beyond

 

Are you really going to notify 600 sites? George Washington University (gwu.edu <http://gwu.edu> ) was one of them, too.





that the "text" role has been removed from the draft spec, will not be
in 1.1, but will likely come back with a new name and clearer
documentation in ARIA next.

 

Please don't alert the public that their "will be" a replacement until there is a spec to point them to.





I also think that any user agent which wishes to keep their support for
the "text" role should continue to do so. I honestly don't want to break
sites (even those which took a risk on adding non-REC attributes to
production sites). I simply don't want to increase the potential number
of sites using (perhaps incorrectly, as a result of confusion) the
"text" role, or ask user agents to add support for it if it is not
already in place.

 

That's fair. Cheers.





--joanie

On 08/10/2016 03:35 AM, James Craig wrote:



Earlier this Summer, I asked Simon Pieters from Opera to spider some
results related to the text role removal. The results came in yesterday.

In addition to the Apple sites previously mentioned, at the time of its
removal from the spec, the text role was used on at least 600 sites.
Many (not all) of these sites include it because it is used in the
popular jQuery JavaScript library for ratings widgets. I scanned the
list quickly and I did not recognize any big sites other than
potentially "Bed, Bath, and Beyond." Nevertheless, implementation in 2
major browsers, 1 major JavaScript framework, and over 600 sites
indicates its usage is undeniable. 

Here's the evidence:
https://gist.github.com/zcorpan/02c3dc7d85c54a17c15500a24fc692a9

I consider this justification for publishing an ARIA 1.2 with the "text"
role change proposal by Joanie, named "static" or something similar,
with prose updates to make its usage and implementation more clear.
Because of the above usage justification, the spec should also include a
deprecated-but-valid synonym role, "text". 

To keep the release small and avoid scope creep, I propose the inclusion
criteria for ARIA 1.2 be limited to updates that reflect the current
state of the Web as it is today (e.g. include the "text" role) and any
updates to correct or deprecate any existing use of ARIA the working
group considers problematic (e.g. deprecate the "text" role in favor of
the better-named or clearer synonym). 

James





On Aug 5, 2016, at 6:22 AM, Richard Schwerdtfeger
<richschwer@gmail.com  <mailto:richschwer@gmail.com%20%3cmailto:richschwer@gmail.com> <mailto:richschwer@gmail.com>> wrote:

Michiel,

It will not be brought back in 1.1. The group reached consensus, not
once but twice. 

We cannot hold up HTML and SVG any longer. Furthermore, the 2
implementations on the Apple platform were brought up previously.
There is no new information here. Additionally, one of those
platforms, iOS, has no conformant mappings in our specs. 

We can take this up again for ARIA beyond 1.1. I would recommend that
you push for an ARIA 1.2 if you desire this feature sooner. However,
right now the group needs to focus on getting ARIA 1.1 done. We need
test cases, an automated test harness, and so on. There are far bigger
issues with Web Components that we need to get started on. 

Rich





On Aug 4, 2016, at 9:32 PM, Michiel Bijl <michiel@agosto.nl <mailto:michiel@agosto.nl%0b%3cmailto:michiel@agosto.nl> 
<mailto:michiel@agosto.nl>> wrote:

I would like to add my support to bringing back role=text.

—Michiel

On 24 Jun 2016, at 19:07, Steve Faulkner <faulkner.steve@gmail.com <mailto:faulkner.steve@gmail.com%0b%3cmailto:faulkner.steve@gmail.com> 
<mailto:faulkner.steve@gmail.com>> wrote:




+1 to James re adding back to the spec as it is implemented in
multiple browsers and being used, therefore requires it be defined.
If there are warnings required they should be noted in the section
specifying the feature. 

Regards

Stevef

On Friday, 24 June 2016, James Craig <jcraig@apple.com <mailto:jcraig@apple.com%0b%3cmailto:jcraig@apple.com> 
<mailto:jcraig@apple.com>> wrote:

   Clarifying my concern with the text role removal. Apologies that
   I did not notice the change sooner.

   My objection was not to an incomplete issue being postponed to
   ARIA 2.0. I objected to the removal of a *feature* that had been
   in the spec for years and was already implemented in two
   browsers. To my recollection, we never did that in ARIA 1.0.
   Furthermore, I'm not sure there is W3C precedent for removing a
   feature that has already met its exit criteria. 

     * It was one of the first features approved by the working
       group for ARIA 1.1, and had been in the spec for more than 2
       years.
     * The related-but-separate "text range/selection/copy" issues
       had been discussed and punted to 2.0 during the Toronto
       Face-to-Face in January 2014.
     * 2 of the 4 major browsers have implemented the feature.
     * The feature is used on a number of sites including major
       ones (I know of the iTunes Media Stores, for example)
     * There is no serious objection from one of the other vendors
       (e.g. "Not implementable on our platform.")


   Therefore, the feature should not have been removed from the
   spec. More importantly, because of the above proofs, it should
   follow the HTML model, and be added back in, to match the Web as
   it is today.

   James




-- 
--

Regards

SteveF
Current Standards Work @W3C
<http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>