- From: Joanmarie Diggs <jdiggs@igalia.com>
- Date: Thu, 21 May 2015 16:40:21 -0400
- To: Richard Schwerdtfeger <schwer@us.ibm.com>, James Craig <jcraig@apple.com>
- CC: PF <public-pfwg@w3.org>, WAI XTech <wai-xtech@w3.org>
Hey Rich, all.
On 05/21/2015 02:50 PM, Richard Schwerdtfeger wrote:
> There are more than things like roles that we need to test for. Also,
> the DOM is very short sighted. As you know more and more content is
> being injected into web pages that we will never see show up in the DOM.
> Element.getComputedRole is a non-starter.
Maybe; maybe not. It's not ready to go, but I'm not sure it's a
non-starter. I just did a quick test with WebKit's Web Inspector in both
Linux and OS X, injecting some content via CSS:
------------
p::before { content: "Do NOT "; }
<div role="switch" aria-checked="true" aria-labelledby="label"></div>
<p id="label">toggle me</p>
------------
On both platforms, for the Accessibility panel I see:
Div:
* Role: switch
* Label: Do NOT toggle me
* Checked: Yes
Paragraph:
* Role: No exact ARIA role match
For OS X, the paragraph element shows 1 child with role(text). For
Linux, the paragraph element lacks this. This is consistent with our
individual platforms: OS X exposes rendered text through StaticTextRole
children; ATK flattens the content into the parent.
The injected content is there, both in the Web Inspector, and in the
accessibility inspectors.
The problem with the computed role is that it doesn't tell you the
mapping for the platform; just the exposure via WebCore. If you look at
the test case with Accerciser, you'll see the switch is exposed with a
role of toggle button. Do the same with Accessibility Inspector and
you'll see it's a checkbox with subrole of switch. And if we're going to
do more than just ARIA testing, "No exact ARIA role match" is not
especially helpful. But those issues are quite easy to fix, either by
modifying the existing behavior or through new API.
--joanie
Received on Thursday, 21 May 2015 20:41:32 UTC