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

Thanks for the detailed reply, Joanie,

I didn't mean to completely take over the discussion of ARIA 1.2, or
suggest there would be no other purpose for an update to ARIA in the next
year.

I do think the Graphics module is the correct place for a "graphical text"
role.  The question is, whether that role (as I described it) covers all
the desired use cases for a text/static role.  I see three purposes, all of
which are covered by the name graphics-text:

   - an image or drawing element used to represent text

   - emoji or other symbol characters where the basic unicode names do not
   convey the correct meaning

   - complex formatted text where the meaning is lost without the
   formatting (e.g., the example of a price where the cents are indicated with
   a superscript layout but there is no actual decimal character in the text)
   or where the formatting markup compromises readability (e.g., text where
   each letter is its own element to create an animated effect, but it should
   still be read as continuous words)

I hope that the "graphics-" prefix explains the narrow purpose of the role
(graphical or decorative text) clearly enough that we don't have the same
confusion that role=text created.

I personally found the "static" name very confusing and inconsistent with
how I interpreted the role.  That suggests that other people were seeing
the role quite differently, as a way of making complex content inert and
flat.

If there are use-cases for "static" which can't logically be described as
"graphical text" or "decorative text", then maybe the Graphics module is
not the correct place. But I haven't yet seen an example of this.

Thanks for the link to the draft of the static role definition.  I'd
forgotten about the "flattening extra markup" example, and will want to
include that as a case where the accessible name comes from contents.

Best,
~Amelia


On 11 August 2016 at 17:27, Joanmarie Diggs <jdiggs@igalia.com> wrote:

> Hi all.
>
> On 08/11/2016 05:42 PM, James Craig wrote:
>
> > Joanie may have another name suggestion than "graphics-text" since she
> > objected to primarily to the "text" moniker.
>
> I'm not wedded to (or jazzed by) "static," but "static" seemed like a
> more accurate and potentially less confusing role name. And no one had a
> better idea. So that's why "static" was chosen during the rewrite.
>
> > Again, I don't think that's necessary to suggest the "text" alias.
>
> And I would again add that not only is it not necessary, but it is also
> not desirable to suggest it.
>
> Again, if user agents just happen to maintain their already existing
> support for "text" under the hood, that's fine with me. I simply don't
> think we want to advertise this role/functionality under the name "text"
> for the reasons I have already stated on quite a few occasions.
>
> >> This would also be a good time to mention any other conditions or
> >> restrictions (from previous drafts of the text role prose) you think
> >> should be included.
> >
> > Joanie wrote the best draft, so she can point you to the latest
> iteration.
>
> https://rawgit.com/w3c/aria/archive-static-and-text-roles/ar
> ia/aria.html#static
>
> As for moving this role into the Graphics spec.... I'm not opposed to
> it, though I have my doubts at the moment: If the reason for moving it
> to Graphics is that the role really had no business being in the ARIA
> spec in the first place -- and truly does belong in the Graphics spec
> instead -- that would go quite a ways towards eliminating my doubts. But
> IF instead the general belief is that this role does belong in the ARIA
> spec, but we ran out of time before reaching consensus, and we don't
> want to invest the time and effort to do a 1.2, and the Graphics spec
> editor volunteered to take it on.... Well.... It's an extremely nice and
> practical offer and solution. But I'm afraid it seems like a hack to me.
> (A nice, practical, and appreciated hack designed to address a stated
> need in a timely fashion, but a hack nonetheless.)
>
> In addition, I don't think it's safe (yet) to say we would be doing a
> 1.2 release chiefly or solely for this role. There were other things we
> discussed postponing to 1.2. I don't recall the full list, but a few
> candidates which spring to my mind are:
>
> 1. Indicating obfuscated characters if we conclude we need a solution
>    (but not a role) to make custom password fields more accessible.
>    Someone (I forget who at the moment) proposed an attribute. If the
>    attribute contained the obfuscated character used, ATs could echo
>    that upon keypress and avoid doing the work to get the rendered
>    text.
>
> 2. Restricting the use of aria-roledescription to elements which have
>    an accessible name. I mentioned that during Matt's re-vamp of the
>    property, but did so too late for 1.1. I still believe it needs
>    doing. Remember that "love" <fingerquotes>role</fingerquotes>?
>
> 3. Considering an attribute for exposing a braille version for the
>    roledescription. Some braille users prefer abbreviated role names
>    because braille-display real estate is expensive and having to
>    scroll frequently is not desired. That's why some screen readers
>    provide localized, abbreviated braille role names (e.g. tglbtn for
>    toggle button). Now that we have aria-roledescription, braille users
>    are going to find that they have to scroll more. Maybe they won't
>    care, in which case never mind. But if the users do care, it might
>    be nice to have a means for authors to provide the abbreviated role
>    for braille displays in addition to the full spoken role.
>
> 4. Didn't ETS have some testing-related needs we didn't manage to get
>    done in time for 1.1?
>
> 5. Other stuff we don't yet know about because implementors still have
>    to implement parts of 1.1, ATs still have to add some support,
>    authors need to use it, and AT users need to encounter it in the
>    wild. Then we'll discover stuff we didn't anticipate and may
>    wish to address prior to 2.0.
>
> That said, it doesn't mean the text/static/graphcis-text role does not
> belong in the Graphics spec. Maybe it does. That's up for the group to
> decide. But I think the decision should be based on -- or at least
> heavily weighted by -- where it truly belongs rather than what is most
> expedient.
>
> --joanie
>
>