Re: Element.getComputedRole() + Element.getUIBehaviors()

Karl,
I believe that it has been stated in the past that for security reasons 
that information cannot be exposed with a JS interface.
Regards,
James


On 11/26/2014 2:08 PM, Karl Groves wrote:
> I believe the event information has usefulness beyond accessibility. 
> The fact that existing monkey patches exist in tools like Firebug 
> demonstrates this, as does the fact that the browsers have this in 
> their own devtools. In this case all that would be needed is exposing 
> that same information.
>
> On Wed, Nov 26, 2014 at 4:53 PM, James Nurthen 
> <james.nurthen@oracle.com <mailto:james.nurthen@oracle.com>> wrote:
>
>     Karl,
>     I believe retrieving the name and role are very useful. I have no
>     issues with these.
>     I believe retrieving whether a given element has certain event
>     handlers on it is relatively useless as with event propagation in
>     many frameworks determining if an individual element has an event
>     handler is not useful.
>
>     Regards,
>     James
>
>
>
>     On 11/26/2014 1:42 PM, Karl Groves wrote:
>>>     What should web accessibility evaluation tools check?
>>     Things that they can determine to close to 100% accuracy that
>>     there is a real issue. False positives or warnings are a real
>>     problem for both developers and testers.
>>
>>
>>     (Apologies for broken quoting)
>>
>>     The above isn't really relevant to the conversation at hand. Or,
>>     maybe it is: The ability to natively retrieve an object's
>>     computed role, state, value, and other information can (should?)
>>     only lead to more accurate testing. Whether or not an automated
>>     tool actually benefits from this information is up to them. Its
>>     sort of a horse-to-water sort of thing. Just as the user of an an
>>     assistive technology should be able to make certain assumptions
>>     based on an element's role,  a testing tool should be able to
>>     apply specific checks to an object based on its role. Whether or
>>     not the tool does so is up to the vendor. In other words, *not*
>>     providing this information only hampers the ability of good tools
>>     that can use it.
>>
>>
>>
>>
>>     On Wed, Nov 26, 2014 at 4:12 PM, James Nurthen
>>     <james.nurthen@oracle.com <mailto:james.nurthen@oracle.com>> wrote:
>>
>>
>>         On 11/26/2014 11:38 AM, Gunderson, Jon R wrote:
>>>         James,
>>>
>>>         Sorry to keep bugging you about this topic, but I just want
>>>         to make sure I fully understand what you are saying.
>>>
>>>         When are web accessibility evaluation tools useful?
>>         I'm not sure I need to answer this question. I'm not sure
>>         what you are hoping to learn from asking it.
>>>
>>>         What should web accessibility evaluation tools check?
>>         Things that they can determine to close to 100% accuracy that
>>         there is a real issue. False positives or warnings are a real
>>         problem for both developers and testers.
>>
>>         It is my contention that any checks which rely on getting
>>         these UI behaviours will result in many more false positives
>>         and manual checks and cannot ever result in the detection at
>>         a level even approaching 100% reliability of any errors.
>>         Therefore I do not see the value in adding it.
>>
>>         Regards,
>>         James
>>>
>>>         Thanks,
>>>         Jon
>>>
>>>
>>>         From: James Nurthen <james.nurthen@oracle.com
>>>         <mailto:james.nurthen@oracle.com>>
>>>         Organization: Oracle Corporation
>>>         Date: Wednesday, November 26, 2014 at 1:19 PM
>>>         To: Jon Gunderson <jongund@illinois.edu
>>>         <mailto:jongund@illinois.edu>>, "public-pfwg@w3.org
>>>         <mailto:public-pfwg@w3.org>" <public-pfwg@w3.org
>>>         <mailto:public-pfwg@w3.org>>
>>>         Subject: Re: Element.getComputedRole() +
>>>         Element.getUIBehaviors()
>>>
>>>         Jon,
>>>         Please see inline.
>>>
>>>         On 11/26/2014 11:04 AM, Gunderson, Jon R wrote:
>>>>         James,
>>>>
>>>>         What if a development team does not understand they need to
>>>>         support the keyboard or add ARIA roles to a widget they are
>>>>         building accessible, you would rather an evaluation tools
>>>>         be silent?
>>>         If a team does not understand that everything needs to be
>>>         keyboard accessible then I do not believe they will be
>>>         running accessibility evaluation tools on their products.
>>>
>>>         Every time new warnings or false positives are introduced it
>>>         leads to at least 2 possible harmful scenarios.
>>>         The first is that people ignore the warnings / false
>>>         positives due to investigating one or 2, finding they are no
>>>         issue and then assuming all the others follow the same pattern.
>>>         The second is that they modify their code to make the
>>>         warnings / false positives go away. When these modifications
>>>         are not necessary this is either wasted developer time which
>>>         could have been spent on other issues or, even worse, end up
>>>         negatively affecting the accessibility of the product. In
>>>         the example cited I would bet many developers would end up
>>>         adding tabindex=0 and a role which would lead to decreased
>>>         accessibility dues to an extra tab-stop for the redundant
>>>         control.
>>>
>>>         I don't see how adding something like this benefits anyone.
>>>
>>>         Regards,
>>>         James
>>>
>>>>
>>>>         Doesn’t this lead to people thinking or even claiming
>>>>         accessibility when they are not?
>>>>
>>>>         There are a lot of newbies out there who do not understand
>>>>         ARIA technology and are creating very inaccessible web
>>>>         resources.
>>>>
>>>>         Jon
>>>>
>>>>         From: James Nurthen <james.nurthen@oracle.com
>>>>         <mailto:james.nurthen@oracle.com>>
>>>>         Organization: Oracle Corporation
>>>>         Date: Wednesday, November 26, 2014 at 12:33 PM
>>>>         To: "public-pfwg@w3.org <mailto:public-pfwg@w3.org>"
>>>>         <public-pfwg@w3.org <mailto:public-pfwg@w3.org>>
>>>>         Subject: Re: Element.getComputedRole() +
>>>>         Element.getUIBehaviors()
>>>>         Resent-From: "public-pfwg@w3.org
>>>>         <mailto:public-pfwg@w3.org>" <public-pfwg@w3.org
>>>>         <mailto:public-pfwg@w3.org>>
>>>>         Resent-Date: Wednesday, November 26, 2014 at 12:34 PM
>>>>
>>>>         Jon,
>>>>         If this were to be keyboard focusable then I agree it would
>>>>         need a role - but without a keyboard focus I think it is
>>>>         more likely to be a secondary method of accomplishing a
>>>>         task - and any tool that starts reporting things like this
>>>>         is going to end up requiring users to perform so many
>>>>         manual checks that they end up not doing them. We can
>>>>         already determine if something can take a keyboard focus so
>>>>         I believe we can already cover this where necessary.
>>>>
>>>>         Regards,
>>>>         James
>>>>
>>>>
>>>>         On 11/26/2014 10:10 AM, Gunderson, Jon R wrote:
>>>>>         James,
>>>>>
>>>>>         There are situations where event information will be more
>>>>>         or less useful, but without some type of event information
>>>>>         it is impossible through the standard DOM to identify
>>>>>         elements that may need ARIA roles (I.e. <div
>>>>>         onmousedown=“someEvent”).
>>>>>
>>>>>         Do you agree with that?
>>>>>
>>>>>         Jon
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>         From: James Nurthen <james.nurthen@oracle.com
>>>>>         <mailto:james.nurthen@oracle.com>>
>>>>>         Organization: Oracle Corporation
>>>>>         Date: Wednesday, November 26, 2014 at 12:03 PM
>>>>>         To: Jon Gunderson <jongund@illinois.edu
>>>>>         <mailto:jongund@illinois.edu>>, "public-pfwg@w3.org
>>>>>         <mailto:public-pfwg@w3.org>" <public-pfwg@w3.org
>>>>>         <mailto:public-pfwg@w3.org>>
>>>>>         Subject: Re: Element.getComputedRole() +
>>>>>         Element.getUIBehaviors()
>>>>>
>>>>>         Jon,
>>>>>         In many frameworks all of these events will be handled at
>>>>>         the page level. I don't think you are going to get any
>>>>>         useful information from these rules.
>>>>>         Regards,
>>>>>         James
>>>>>
>>>>>         On 11/26/2014 9:58 AM, Gunderson, Jon R wrote:
>>>>>>         James,
>>>>>>
>>>>>>         I agree, any accessibility rules related to events have
>>>>>>         to take into account event bubbling.
>>>>>>
>>>>>>         There are two main types of rules this type of function
>>>>>>         supports:
>>>>>>
>>>>>>          1. A element has some type of behavior that needs an
>>>>>>             ARIA role, for example:
>>>>>>
>>>>>>         <div onClick=“submitForm”>Submit</div>
>>>>>>
>>>>>>         2. An element has some ARIA widget role that requires
>>>>>>         keyboard support, but there is no keyboard event handler
>>>>>>         that the element can respond to, even when event bubbling
>>>>>>         is taken into account.
>>>>>>
>>>>>>         Jon
>>>>>>
>>>>>>         From: James Nurthen <james.nurthen@oracle.com
>>>>>>         <mailto:james.nurthen@oracle.com>>
>>>>>>         Organization: Oracle Corporation
>>>>>>         Date: Wednesday, November 26, 2014 at 11:45 AM
>>>>>>         To: "public-pfwg@w3.org <mailto:public-pfwg@w3.org>"
>>>>>>         <public-pfwg@w3.org <mailto:public-pfwg@w3.org>>
>>>>>>         Subject: Re: Element.getComputedRole() +
>>>>>>         Element.getUIBehaviors()
>>>>>>         Resent-From: "public-pfwg@w3.org
>>>>>>         <mailto:public-pfwg@w3.org>" <public-pfwg@w3.org
>>>>>>         <mailto:public-pfwg@w3.org>>
>>>>>>         Resent-Date: Wednesday, November 26, 2014 at 11:45 AM
>>>>>>
>>>>>>         +1
>>>>>>
>>>>>>         On 11/26/2014 9:41 AM, Dominic Mazzoni wrote:
>>>>>>>         As before my main concern with this type of function is
>>>>>>>         that it's impossible to implement correctly, and
>>>>>>>         therefore it's quite misleading and of dubious value.
>>>>>>>         Event delegation is an extremely common pattern in web
>>>>>>>         apps, and there's no way to know whether an element is
>>>>>>>         being listened to by an event handler on a different
>>>>>>>         element or not.
>>>>>>>
>>>>>>>         On Wed, Nov 26, 2014 at 9:07 AM, Gunderson, Jon R
>>>>>>>         <jongund@illinois.edu <mailto:jongund@illinois.edu>> wrote:
>>>>>>>
>>>>>>>             Rich and Dominic,
>>>>>>>
>>>>>>>             What do you think about a element method called
>>>>>>>             getUIBehavior()?
>>>>>>>
>>>>>>>             interface Element : Node {
>>>>>>>
>>>>>>>                Boolean  getUIBehaviors(in DOMString name);
>>>>>>>
>>>>>>>             }
>>>>>>>
>>>>>>>             DOMString values:
>>>>>>>
>>>>>>>             ‘click’ : Returns true if node has at least one event handler for the following events “onclick” or “ondbclick” events
>>>>>>>
>>>>>>>             ‘keyboard’ : Returns true if node has at least one event handler for the following events “onKeyPress”, “onKeyDown or “onKeyUp” events
>>>>>>>
>>>>>>>             ‘mouse’ : Returns true if node has at least one event handler for “onMouseXXX” events
>>>>>>>
>>>>>>>             ‘change’ : Returns true if node has at “onChange” event
>>>>>>>
>>>>>>>             “focus”  : Returns  true if node has at “onFocus” event
>>>>>>>
>>>>>>>             “blur”  : Returns  true if node has at “onBlur” event
>>>>>>>
>>>>>>>             “drag” :Returns true if node has at least one event handler for “onDragXXX” events
>>>>>>>
>>>>>>>             “css”  :Returns true if node has at least one event handler for “animationXXX” events or “transitionend” event
>>>>>>>
>>>>>>>
>>>>>>>             From: Dominic Mazzoni <dmazzoni@google.com
>>>>>>>             <mailto:dmazzoni@google.com>>
>>>>>>>             Date: Thursday, October 16, 2014 at 3:51 PM
>>>>>>>             To: Richard Schwerdtfeger <schwer@us.ibm.com
>>>>>>>             <mailto:schwer@us.ibm.com>>
>>>>>>>             Cc: "public-pfwg@w3.org <mailto:public-pfwg@w3.org>"
>>>>>>>             <public-pfwg@w3.org <mailto:public-pfwg@w3.org>>
>>>>>>>             Subject: Re: Element.getComputedRole()
>>>>>>>             Resent-From: "public-pfwg@w3.org
>>>>>>>             <mailto:public-pfwg@w3.org>" <public-pfwg@w3.org
>>>>>>>             <mailto:public-pfwg@w3.org>>
>>>>>>>             Resent-Date: Thursday, October 16, 2014 at 3:52 PM
>>>>>>>
>>>>>>>             Sure, I think it's a good idea.
>>>>>>>
>>>>>>>             How about getComputedAccessibleText next?
>>>>>>>
>>>>>>>             In both Blink and WebKit I imagine we'll have to
>>>>>>>             think about efficiency when implementing this -
>>>>>>>             typically we enable accessibility lazily and then
>>>>>>>             leave it on - at least for that page. We'd want to
>>>>>>>             use the real accessibility code to compute this, but
>>>>>>>             then disable accessibility support and clean up if
>>>>>>>             it wasn't enabled previously.
>>>>>>>
>>>>>>>
>>>>>>>             On Thu, Oct 16, 2014 at 1:19 PM, Richard
>>>>>>>             Schwerdtfeger <schwer@us.ibm.com
>>>>>>>             <mailto:schwer@us.ibm.com>> wrote:
>>>>>>>
>>>>>>>                 Hi Dominic,
>>>>>>>
>>>>>>>                 We have an issue to add a getComputedRole()
>>>>>>>                 function on  Element. This would help
>>>>>>>                 application developers as well as accessibility
>>>>>>>                 test tools. Here is the issue:
>>>>>>>
>>>>>>>                 https://www.w3.org/WAI/PF/Group/track/issues/427
>>>>>>>
>>>>>>>                 Would you support implementing this feature in
>>>>>>>                 Chrome?
>>>>>>>
>>>>>>>                 Thanks,
>>>>>>>
>>>>>>>                 Rich
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>                 Rich Schwerdtfeger
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>         -- 
>>>>>>         Regards, James
>>>>>>
>>>>>>         Oracle <http://www.oracle.com>
>>>>>>         James Nurthen | Principal Engineer, Accessibility
>>>>>>         Phone: +1 650 506 6781 <tel:+1%20650%20506%206781> |
>>>>>>         Mobile: +1 415 987 1918 <tel:+1%20415%20987%201918>
>>>>>>         Oracle Corporate Architecture
>>>>>>         500 Oracle Parkway | Redwood City, CA 94065
>>>>>>         Green Oracle <http://www.oracle.com/commitment>Oracle is
>>>>>>         committed to developing practices and products that help
>>>>>>         protect the environment
>>>>>>
>>>>>
>>>>>         -- 
>>>>>         Regards, James
>>>>>
>>>>>         Oracle <http://www.oracle.com>
>>>>>         James Nurthen | Principal Engineer, Accessibility
>>>>>         Phone: +1 650 506 6781 <tel:+1%20650%20506%206781> |
>>>>>         Mobile: +1 415 987 1918 <tel:+1%20415%20987%201918>
>>>>>         Oracle Corporate Architecture
>>>>>         500 Oracle Parkway | Redwood City, CA 94065
>>>>>         Green Oracle <http://www.oracle.com/commitment>Oracle is
>>>>>         committed to developing practices and products that help
>>>>>         protect the environment
>>>>>
>>>>
>>>>         -- 
>>>>         Regards, James
>>>>
>>>>         Oracle <http://www.oracle.com>
>>>>         James Nurthen | Principal Engineer, Accessibility
>>>>         Phone: +1 650 506 6781 <tel:+1%20650%20506%206781> |
>>>>         Mobile: +1 415 987 1918 <tel:+1%20415%20987%201918>
>>>>         Oracle Corporate Architecture
>>>>         500 Oracle Parkway | Redwood City, CA 94065
>>>>         Green Oracle <http://www.oracle.com/commitment>Oracle is
>>>>         committed to developing practices and products that help
>>>>         protect the environment
>>>>
>>>
>>>         -- 
>>>         Regards, James
>>>
>>>         Oracle <http://www.oracle.com>
>>>         James Nurthen | Principal Engineer, Accessibility
>>>         Phone: +1 650 506 6781 <tel:+1%20650%20506%206781> | Mobile:
>>>         +1 415 987 1918 <tel:+1%20415%20987%201918>
>>>         Oracle Corporate Architecture
>>>         500 Oracle Parkway | Redwood City, CA 94065
>>>         Green Oracle <http://www.oracle.com/commitment>Oracle is
>>>         committed to developing practices and products that help
>>>         protect the environment
>>>
>>
>>         -- 
>>         Regards, James
>>
>>         Oracle <http://www.oracle.com>
>>         James Nurthen | Principal Engineer, Accessibility
>>         Phone: +1 650 506 6781 <tel:+1%20650%20506%206781> | Mobile:
>>         +1 415 987 1918 <tel:+1%20415%20987%201918>
>>         Oracle Corporate Architecture
>>         500 Oracle Parkway | Redwood City, CA 94065
>>         Green Oracle <http://www.oracle.com/commitment> Oracle is
>>         committed to developing practices and products that help
>>         protect the environment
>>
>>
>>
>>
>>     -- 
>>     Karl Groves
>>     Senior Technical Lead Accessibility Software Consultant &
>>     Director of Training
>>     The Paciello Group
>>     @karlgroves
>>     Phone: +1 443-875-7343 <tel:%2B1%20443-875-7343>
>
>     -- 
>     Regards, James
>
>     Oracle <http://www.oracle.com>
>     James Nurthen | Principal Engineer, Accessibility
>     Phone: +1 650 506 6781 <tel:+1%20650%20506%206781> | Mobile: +1
>     415 987 1918 <tel:+1%20415%20987%201918>
>     Oracle Corporate Architecture
>     500 Oracle Parkway | Redwood City, CA 94065
>     Green Oracle <http://www.oracle.com/commitment> Oracle is
>     committed to developing practices and products that help protect
>     the environment
>
>
>
>
> -- 
> Karl Groves
> Senior Technical Lead Accessibility Software Consultant & Director of 
> Training
> The Paciello Group
> @karlgroves
> Phone: +1 443-875-7343

-- 
Regards, James

Oracle <http://www.oracle.com>
James Nurthen | Principal Engineer, Accessibility
Phone: +1 650 506 6781 <tel:+1%20650%20506%206781> | Mobile: +1 415 987 
1918 <tel:+1%20415%20987%201918>
Oracle Corporate Architecture
500 Oracle Parkway | Redwood City, CA 94065
Green Oracle <http://www.oracle.com/commitment> Oracle is committed to 
developing practices and products that help protect the environment

Received on Wednesday, 26 November 2014 22:14:19 UTC