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

Amelia,

 

Thank you for a concise list of what you understand to be the objectives of the graphics-text role. I’d like to use it to hone in on the problem we are solving for assistive technology users.

 

You wrote:

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

 

If you think about this strictly from the perspective of screen reader users, the third use is distinctly different from the first two. 

 

In the first two cases, graphical elements are present. In those cases, it is extremely important that the presence of the graphical elements is not hidden from screen readers. The purpose of giving authors an alternative to the img role would be to indicate to screen readers the specific purpose of the graphical element so screen readers have the OPTION of treating it differently from other graphics. 

 

The third use is distinctly different because the element in question is actually text that is decorated in a way that has meaning; there is not a graphical element present. In this case, the content should be treated as text. It would be useful to compile a list of use cases that fall into this category to see if there is a need for ARIA to do anything new to address them. In every case of which I am aware, there is already a way to achieve a good accessible result. Adding a new role would simply be a form of alternative coding as opposed to a way of adding missing accessibility information, which is the purpose of ARIA. If there are use cases for which there is no way to communicate the meaning of the decoration, then that is a different problem that would require screen reader behaviors that are quite different from the first two uses you listed.

 

Matt King

 

From: Amelia Bellamy-Royds [mailto:amelia.bellamy.royds@gmail.com] 
Sent: Friday, August 12, 2016 9:26 AM
To: Joanmarie Diggs <jdiggs@igalia.com>; James Craig <jcraig@apple.com>
Cc: Accessible Rich Internet Applications Working Group <public-aria@w3.org>
Subject: 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 <mailto: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/aria/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