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

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

Received on Thursday, 11 August 2016 23:28:13 UTC