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

+1 to this idea. Some notes below.

> On Aug 10, 2016, at 10:45 AM, Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com> wrote:
> 
> As an alternative to creating ARIA 1.2 solely for this role, we could add a graphics-text role to the Graphics module, with text as a deprecated synonym.  As I've mentioned previously, the only reason we didn't add a graphical text role to the module is because we expected to be able to use the text role for this purpose.
> 
> The description would be along the lines of:
> 
> graphics-text
> 
> A graphical object (e.g., image or SVG path) that is used to represent text.


> The text equivalent MUST be provided by the author as the element's accessible name.  

This RFC requirement should not be necessary. NameFrom: contents would allow work for concatenated results.

contents: <div role="text">foo <img … alt="bar"> baz</div>
author: <div role="text" aria-label="foor bar baz">foo <img> baz</div>


> User agents MUST support the role "text" as a synonym for graphics-text.

I don't think we need this requirement, and Joanie would certainly object.

> Authors SHOULD NOT use the synonym in new content.

Eh. Remove this too. We should only recommend against this once every common browser that currently supports "text" also supports "graphics-text"

> The graphics-text role may also be used to assign a text equivalent to a static text element, when the plain text content of the element does not correctly represent the meaning of the element in context.  For example, the "black heart" character might represent the text "love", or a sequence of filled and unfilled star characters might represent the text "3 out of 5 stars".  In this usage, the graphics-text role is similar to applying an img role on a text container element, except that it also indicates that the image's accessible name is read as part of the surrounding text flow.
> 
> [examples]
> 
> Authors should note that declaring an element as graphical text does not replace all the functionality of real text, such as the ability to search for and select text characters.  Real text SHOULD be used whenever possible.  Authors SHOULD NOT use the graphics-text role when the element's plain text content correctly represents the graphical text, such as an SVG text element, or an HTML canvas element with text in its fallback DOM.  Authors MUST NOT use the graphics-text role when the element has any focusable child elements, and user agents MUST ignore the role in that case.
> 
> 
> (That last sentence could be replaced by a link to common rules for ignoring all children-are-presentational roles, if it exists.)
> 
> 
> ~Amelia
> 
> 
> 
> On 10 August 2016 at 09:29, 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....
> 
> I think it's awesome that Simon did this research for us. Thank you for
> asking him to. Let's notify the jQuery folks and Bed, Bath, and Beyond
> 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.
> 
> 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.
> 
> --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 <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
> >
> >