- From: James Craig <jcraig@apple.com>
- Date: Mon, 10 Nov 2014 10:32:46 -0800
- To: David Bolter <dbolter@mozilla.com>, Alexander Surkov <surkov.alexander@gmail.com>, Dominic Mazzoni <dmazzoni@google.com>
- Cc: PF <public-pfwg@w3.org>, Chris Fleizach <cfleizach@apple.com>
Discussed this with the WebApps and HTML working groups at TPAC. General consensus seemed to be that these methods should be directly on Element rather than defining a new AccessibilityElement interface.
> On Oct 16, 2014, at 10:30 PM, James Craig <jcraig@apple.com> wrote:
>
> Alex Surkov wrote:
>
>>> 2) it doesn't make sense to expose accessible properties on every DOM
>>> element (like on inaccessible DOM elements) and Element API approach cannot
>
> ...
>
>>> I would design an Accessible interface instead following the accessibility
>>> desktop APIs.
>>> interface Accessible {
>>> string role;
>>> };
>>>
>>> Then DOM Window object can be extended by:
>>> interface Window {
>>> Accessible getAccessibleFor(Node aNode);
>>> };
>
>
> The "'Accessible' adjective used as noun" makes for awkward API. What about "AccessibleElement" or "AccessibilityElement" instead?
>
> interface AccessibilityElement {
> // Some of these might not need to be an accessors methods. Could be string properties as you suggested.
> String computedRole();
> String computedLabel();
> Element element(); // reverse relationship back to DOM element, or null.
> AccessibilityElement accessibilityParentElement();
> Array accessibilityChildren();
> };
> partial interface Element {
> AccessibilityElement accessibilityElement();
> };
>
>
> Dominic wrote:
>
>> 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.
>
> +Chris, who had similar concerns.
>
>
Received on Monday, 10 November 2014 18:33:19 UTC