[Bug 20466] [Accessibility]: Custom element should allow declaration of default accessibility features, such as role and other ARIA attributes.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=20466

--- Comment #7 from James Craig <jcraig@apple.com> ---
(In reply to Dominic Cooney from comment #6)
> (In reply to James Craig from comment #5)
> > (In reply to Dominic Cooney from comment #4)
> > > While I'm NOT the accessibility Dominic, I believe the current thinking is:
> > > 
> > > - UA can respond to ARIA roles inside Shadow DOM. Component authors who want
> > > to be "like native" can use this approach.
> > 
> > There are a few issues with that approach. 
> > 
> > 1. The end result would be an element with a role inside the generic parent
> > element. If the custom element inherits its role from a native one (like the
> > dialog example) there is no way to override it, except to tell all authors
> > to explicitly use role="presentation" on the custom element. 
> 
> Is that a problem?

Sorry, each instance is unique and I did not clearly describe the scenario.
Imagine an the site's lead engineers set up a set of custom element for
non-technical content providers to use. 

The implication was that it some cases, it would be necessary to override the
role, and therefore forcing each user of the tag <x-alert> to include role
attribute and other related markup would be unacceptable, flaky, and defeat
some of the purpose of using a custom element that should be including all of
its own semantics and functionality. 


> The Custom Element can also set the role attribute in the created callback,
> without adding additional machinery to the spec for this.

Perhaps I'm misunderstanding. Are you saying my example would work as-is?

<element extends="dialog" role="alertdialog" name="x-alert"
constructor="AlertDialog">
    …
</element>

Or are you saying the element author should use something like
this.setAttribute('role', 'alertdialog'); in the custom element's constructor?

Or something else entirely? Thanks for clarifying. If this type of thing can
indeed already be done, then all I'd request is an editorial note or example in
the spec stating how that can and should be achieved.

> > 2. I don't believe focus management for shadow DOM components is fully
> > specified, which I hope to raise as an issue on that spec, but is
> > nevertheless a blocker for this suggestion.
> 
> I think focus management in Shadow DOM is unrelated to Custom Elements.

I agree, but it's valid to point out why your suggestion of using the shadow
DOM would not yet work in some cases, and therefore should not be used as
justification for dismissing this bug.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 8 October 2013 06:41:01 UTC