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

The below makes it still more clear to me that what we are trying to do is tell assistive technologies that there is a graphical object present that serves one of 2 special purposes:

1.       Displaying text.

2.       Representing a word or phrase as part of a statement otherwiser written with text.

 

Regardless of how the graphic is drawn, we should never hide the fact that it is a graphic. That information is very important.

 

However, we can let assistive technologies know what the purpose of the graphic is. Then, they can intelligently apply that information to their presentation of the information, perhaps adjusting their behavior based on what the user is doing or on user preferences.

 

Just like many users set their default punctuation level to “All” and many others set it to “some”, there will be some users that always want to be aware of the graphic and others who do not care. Similarly, those needs can change based on circumstance. 

 

Matt

 

From: James Craig [mailto:jcraig@apple.com] 
Sent: Wednesday, August 10, 2016 11:30 AM
To: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>
Cc: Joanmarie Diggs <jdiggs@igalia.com>; 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)

 

+1 to this idea. Some notes below.

 

On Aug 10, 2016, at 10:45 AM, Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com <mailto: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
>
> 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
>
>