W3C home > Mailing lists > Public > public-pfwg@w3.org > October 2014

Re: Element.getComputedRole()

From: James Craig <jcraig@apple.com>
Date: Thu, 16 Oct 2014 22:27:35 -0700
Cc: PF <public-pfwg@w3.org>, Chris Fleizach <cfleizach@apple.com>
Message-Id: <BA039079-FDA8-47A7-8458-08F06BF586DD@apple.com>
To: David Bolter <dbolter@mozilla.com>, Alexander Surkov <surkov.alexander@gmail.com>, Dominic Mazzoni <dmazzoni@google.com>
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 Friday, 17 October 2014 05:29:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:45:10 UTC