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

Hi Matt,

I disagree with this statement at least for SVG.
Regardless of how the graphic is drawn, we should never hide the fact that
it is a graphic. That information is very important.

Some SVG authoring tools generate path elements for everything instead of
using the full suite of drawing primitives; and that is just how they work.
In these cases, there is no attempt by the author to use a symbol for text,
nor is the author avoiding using the text element. In these cases, telling
a user that the text comes from a graphic/path (or n-paths) is not
beneficial, nor does it covey what a sighted user sees.

In some cases, like when the author chooses a unusual font that is unlikely
to be on a user's machine, turning text into a path may be the only way to
ensure the visual appearance of the text is maintained on the user's
machine. Again, because it is captured as a path element is not important
to any user, sighted on not.


                                                              
     Regards,                                                 
                                                              
    Fred Esch                                                 
 Watson, IBM, W3C                                             
  Accessibility                                               
                                                              
 IBM Watson       Watson Release Management and Quality       
                                                              






From: Matt King <a11ythinker@gmail.com>
To: "'James Craig'" <jcraig@apple.com>, "'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>
Date: 08/11/2016 09:18 PM
Subject: 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> 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>
      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
       >
       >