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

FWIW, Figure 1 in the spec makes the distinction between "user agent" as
"browser", and "assistive technology" as something else:
https://w3c.github.io/aria/aria/aria.html#desc_contractmodel

On 2016-06-09 3:11 PM, Joanmarie Diggs wrote:
> 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
>


-- 
;;;;joseph.

'Die Wahrheit ist Irgendwo da Draußen. Wieder.'
                 - C. Carter -

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