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> 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) 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>> 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>> 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>> 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>> 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/>
>>>>> 
>>> 
>> 
>