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

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>
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>
> 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>
>> Organization: Oracle Corporation
>> Date: Wednesday, November 26, 2014 at 1:19 PM
>> To: Jon Gunderson <jongund@illinois.edu>, "public-pfwg@w3.org" <
>> 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>
>> Organization: Oracle Corporation
>> Date: Wednesday, November 26, 2014 at 12:33 PM
>> To: "public-pfwg@w3.org" <public-pfwg@w3.org>
>> Subject: Re: Element.getComputedRole() + Element.getUIBehaviors()
>> Resent-From: "public-pfwg@w3.org" <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>
>> Organization: Oracle Corporation
>> Date: Wednesday, November 26, 2014 at 12:03 PM
>> To: Jon Gunderson <jongund@illinois.edu>, "public-pfwg@w3.org" <
>> 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>
>> Organization: Oracle Corporation
>> Date: Wednesday, November 26, 2014 at 11:45 AM
>> To: "public-pfwg@w3.org" <public-pfwg@w3.org>
>> Subject: Re: Element.getComputedRole() + Element.getUIBehaviors()
>> Resent-From: "public-pfwg@w3.org" <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>
>> 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>
>>> Date: Thursday, October 16, 2014 at 3:51 PM
>>> To: Richard Schwerdtfeger <schwer@us.ibm.com>
>>> Cc: "public-pfwg@w3.org" <public-pfwg@w3.org>
>>> Subject: Re: Element.getComputedRole()
>>> Resent-From: "public-pfwg@w3.org" <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> 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
>>
>> [image: Oracle] <http://www.oracle.com>
>> James Nurthen | Principal Engineer, Accessibility
>> Phone: +1 650 506 6781 <+1%20650%20506%206781> | Mobile: +1 415 987 1918
>> <+1%20415%20987%201918>
>> Oracle Corporate Architecture
>> 500 Oracle Parkway | Redwood City, CA 94065
>> [image: Green Oracle] <http://www.oracle.com/commitment> Oracle is
>> committed to developing practices and products that help protect the
>> environment
>>
>>
>> --
>> Regards, James
>>
>> [image: Oracle] <http://www.oracle.com>
>> James Nurthen | Principal Engineer, Accessibility
>> Phone: +1 650 506 6781 <+1%20650%20506%206781> | Mobile: +1 415 987 1918
>> <+1%20415%20987%201918>
>> Oracle Corporate Architecture
>> 500 Oracle Parkway | Redwood City, CA 94065
>> [image: Green Oracle] <http://www.oracle.com/commitment> Oracle is
>> committed to developing practices and products that help protect the
>> environment
>>
>>
>> --
>> Regards, James
>>
>> [image: Oracle] <http://www.oracle.com>
>> James Nurthen | Principal Engineer, Accessibility
>> Phone: +1 650 506 6781 <+1%20650%20506%206781> | Mobile: +1 415 987 1918
>> <+1%20415%20987%201918>
>> Oracle Corporate Architecture
>> 500 Oracle Parkway | Redwood City, CA 94065
>> [image: Green Oracle] <http://www.oracle.com/commitment> Oracle is
>> committed to developing practices and products that help protect the
>> environment
>>
>>
>>  --
>> Regards, James
>>
>> [image: Oracle] <http://www.oracle.com>
>> James Nurthen | Principal Engineer, Accessibility
>> Phone: +1 650 506 6781 <+1%20650%20506%206781> | Mobile: +1 415 987 1918
>> <+1%20415%20987%201918>
>> Oracle Corporate Architecture
>> 500 Oracle Parkway | Redwood City, CA 94065
>> [image: Green Oracle] <http://www.oracle.com/commitment> Oracle is
>> committed to developing practices and products that help protect the
>> environment
>>
>>
>> --
>> Regards, James
>>
>> [image: Oracle] <http://www.oracle.com>
>> James Nurthen | Principal Engineer, Accessibility
>> Phone: +1 650 506 6781 <+1%20650%20506%206781> | Mobile: +1 415 987 1918
>> <+1%20415%20987%201918>
>> Oracle Corporate Architecture
>> 500 Oracle Parkway | Redwood City, CA 94065
>> [image: 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
>
> [image: Oracle] <http://www.oracle.com>
> James Nurthen | Principal Engineer, Accessibility
> Phone: +1 650 506 6781 <+1%20650%20506%206781> | Mobile: +1 415 987 1918
> <+1%20415%20987%201918>
> Oracle Corporate Architecture
> 500 Oracle Parkway | Redwood City, CA 94065
> [image: 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