Re: Action-2079 + Action-2080 (was Re: ACTION-2080: Draft aria spec text limiting the use of role password on editable objects)

Hey John.

In answer to your question, I mean 'user agent' in the 'browser' sense.
After all, in an accessibility-API-based world, ATs are given accessible
objects with accessible roles. Thus specifying that an AT MUST ignore
something it might not have any way of knowing is a non-starter.

I will leave it up to the group regarding whether or not it is necessary
to specifically say "browser" or "web engine" or something to that effect.

--joanie

On 06/09/2016 02:55 PM, John Foliot wrote:
> Hi Joanie,
> 
> I'm sorry to do this to you, however...
> 
>> User agents MUST ignore the password role when it is applied to
> elements which are neither editable nor explicitly marked as read only.
> 
> Does this then mean that in a code sample like this: <img src=""
> role="password"> that the *browser* (a.k.a. user agent) MUST NOT convey
> the role and value to the AAPI? Or that user agents that rely on the
> AAPI's (a.k.a. screen readers) MUST ignore the fact that this DOM node
> has been 'tagged' as a password widget?
> 
> I'm generally in favor of the W3C's 'user agent' language, but in this
> instance I think more specific clarity would be helpful.
> 
> JF
> 
> 
> On Thu, Jun 9, 2016 at 1:13 PM, Joanmarie Diggs <jdiggs@igalia.com
> <mailto:jdiggs@igalia.com>> wrote:
> 
>     Hi all.
> 
>     During today's ARIA concall we discussed my text for action-2080 in
>     relation to the text Michael wrote for action-2079. The conclusion was
>     that the following sentence should be added to my existing text:
> 
>     "Host languages SHOULD document that the password role can only be used
>     on elements that are editable and not permanently read only."
> 
>     That has been done [1] in my branch [2]. The new proposed text to
>     address both action-2079 and action-2080 is as follows:
> 
>     <quote>
>     Authors SHOULD limit the use of the password role to single-line
>     elements which are editable. Authors MAY use the password role on
>     elements which are not currently editable due to application-specific
>     conditions. However, in that instance, authors MUST indicate that the
>     element is read only by setting aria-readonly to true or using the
>     appropriate native host language attribute. User agents MUST ignore the
>     password role when it is applied to elements which are neither editable
>     nor explicitly marked as read only. Host languages SHOULD document that
>     the password role can only be used on elements that are editable and not
>     permanently read only.
>     </quote>
> 
>     --joanie
> 
>     [1] https://github.com/w3c/aria/commit/9636157
>     [2] https://rawgit.com/w3c/aria/action-2080/aria/aria.html#password
> 
> 
> 
> 
> -- 
> John Foliot
> Principal Accessibility Consultant
> Deque Systems Inc.
> john.foliot@deque.com <mailto:john.foliot@deque.com>
> 
> Advancing the mission of digital accessibility and inclusion

Received on Thursday, 9 June 2016 19:12:56 UTC