Re: Custom tags over wire, was Re: HTMLElement.register--giving components tag names

On 9/2/2011 6:39 PM, Alex Russell wrote:
>> Similarly, WCAG is a series of principles for designing usable, high quality
>> applications.
>>
>>> ARIA presents a set of semantic roles that don't exist in HTML, and
>>> for those, alignment with custom element implementations is
>>> outstanding. Components that express those semantics can use ARIA to
>>> help communicate what they "mean", taking the burden off of the users
>>> of the components to understand and manage the role/state groups.
>>>
>> When working with accessibility, it's super-set of HTML:
>>   img { role: 'img'; };
>>   img[alt=""] { role: 'presentation'; }
>>
>>
>> Yes, I'd like to see Components express aligned semantics, such as
>> button:aria-pressed,
>> in the shadow DOM. It's the same method we use with the Canvas subtree.
> Pseudo-classes as a state mechanism need a lot more examination,
> AFAICT. It's a non-extensible vocabulary, it doesn't appear to be
> scriptable, and as a result, we haven't been able to use them to
> handle things like states for animations (which should be transitions
> between states in a node-graph).
>
> +shans

I meant to short-hand the specs in the "HTML element to Accessibility 
API Role Mapping Matrix":
http://dev.w3.org/html5/html-api-map/#api-role

As evolved from:
2010:
http://www.paciellogroup.com/blog/misc/HTML5/aria-html5-proposal.html
2009:
http://dev.w3.org/html5/markup/aria/


I didn't mean to introduce a new state mechanism. CSS selectors already 
work with ARIA.
With transitions, and generated content, CSS is quite flexible.

This would work fine with transitions:
div[aria-checked="true"] { content: 'Checked'; color: red;}
div[aria-checked="false"] { content: 'Not Checked'; color: black; }

I suspect we're talking about different things.

>> How should ATs be notified/detect that there is a shadow DOM?
> Focus works as it always has. It can move inside the shadow.

Does the following statement make sense?:

ATs that walk the DOM should check for element.shadow [currently 
webkitShadow],
prior to looking for element.childNodes.


>> I'd imagine the accessibility tree simply contains the appropriate data,
>> but for ATs using simple DOM, and getAttribute, should they now check for
>> a .shadow attribute on elements in addition to their usual heuristics?
> That'll work for components with a public shadow, which I think will
> be most of them. Components can also note state by setting role/state
> directly on the outer component.

What of components that contain multiple roles?
Would those components, necessarily, require a public shadow?

There was some discussion about allowing multiple children on the shadow.
Perhaps this would be a good use case for it.


>>>> "data-*" works for arbitrary metadata, and "aria-*"  for UI semantics.
>>>>
>>> Yes! And for low-complexity tasks, they're perfect. For larger,
>>> reusable components that need bundled behavior (Closure, JQuery UI,
>>> Dijit), the task of setting up and managing all of this can be made
>>> easier for users and developers of components by giving them a place
>>> to hang behavior, shadow DOM, and data model concerns from.
>>>
>> We're certainly experimenting, with the Canvas tag and subtree.
> The component approach turns this around, by letting you construct a
> logical tree that might have<canvas>  elements in the shadow, meaning
> you don't need a "hidden tree" per sae.

I like to think that it encapsulates current practice. I'm all for it.
We still need a canvas subtree, to operate with the canvas 2d spec on 
drawFocusRing.

>>>> 4.
>>>> Let's look at the button example:
>>>>
>>>>>>> <button becomes="x-awesome-button">Weee!!</button>
>>>>>>> Becomes:
>>>>>>> <x-awesome-button>Weee!!</x-awesome-button>
>>>>>>>
>>>> For the sake of ATs, that should include ARIA semantics:
>>>> <x-awesome-button role="button" tabindex="0"></x-awesome-botton>
>>>>
>>>> Now the OS and ATs think of that as a button, in every way that<button>
>>>> would be.
>>>> The UA, though, does not; it leaves it up to the scripting environment.
>>>>
>>> There's a lack of terseness here that's sort of concerning. One
>>> possible way forward might be to use "role" as a shorthand for
>>> "becomes" and allow components to register for roles which they
>>> implement. Hmmm.
>>>
>> These extended attributes are something to be managed via script. You would
>> not expect someone to author ARIA states into their static markup, though
>> you would include roles.
>>
>> I do think shorthand is valuable. As I understand it, ARIA tries to stay out
>> of the way.
>> There is no current CSS+ARIA profile, it could be helpful if there were.
> I think this gets back to the idea of "how does a component advertise
> it's state?", and as far as I know, there's no unified approach in the
> web platform. ARIA exists outside of the existing HTML pseudo-class
> system. Anyone who wants to target states with CSS needs an extensible
> vocabulary, and so a lot of stuff gets stuffed into CSS class names
> too. Sort of mess today, and I'd love for us to find a way to unify
> these theories of state.

CSS selectors make this easy enough. ARIA has an extensible vocabulary, 
and CSS has an easy query language.
ARIA is intended to advertise the state of a component. ATs need that 
information.
It was designed to be extensible and non-intrusive.

Yes, items are stuffed into CSS class names currently, as CSS selectors 
did not work with ARIA for some time.
For compatibility, I end up with: <div class="ariaExpanded" 
aria-expanded="true" />

But, that's common for legacy support. For modern browsers, I can drop 
the class name.


>
>> I'm concerned (though I've not investigated), that adding additional
>> behavior to role would be against the traditional non-interference of ARIA
>> on host semantics. CSS on the other hand, certainly changes host semantics.
>>
>> "becomes" as an attribute representing a CSS+ARIA profile, could make some
>> sense. It should give precedent to aria role over the tag name.
>>
>>>> It'd be darn-handy if the UA would enable additional markup, such that:
>>>> <x-awesome-button role="button" style="appearance: button">    would
>>>> inherit
>>>> default events for buttons,
>>>>
>>> In our world, you'd just subclass from HTMLButtonElement in your
>>> component definition to do this.
>>>
>>> Problem solved = )
>>>
>> It's like that in C++ as well, for most of the browser vendors.
>>
>> There's just the issue with all-or-nothing/isolation of behavior.
>>
>> Thus the fears about accessibility of custom components: once you step
>> outside the compiled browser behavior, you lose most of the work vendors put
>> into the UA.
> This is the problem that every JS-built component has today. Web
> Components are a no-op as far as this is concerned.
>
>> How about:<x-awesome-button becomes="button">; incorporating both ARIA and
>> HTML/CSS default events.
> It's unclear why you need both. If x-awesome-button is built as a
> Button subclass, it's all good. If you had<button
> becomes="x-awesome-button">, then you might get some fallback behavior
> for old UAs which might be a win, but tag nesting can get you there
> too.

Fallback behavior is a good thing.

If element.tagName != 'BUTTON', and the element is a button,
element.getAttribute('role') should return 'button'.



>> This is something you'd only use in dynamic dom / shadow dom. Setting
>> becomes would also set the role attribute on the tag.
>>
>> The static dom should still have<button>, or in the worst case,<div
>> role="button">.
> Not sure I understand this point. Can you clarify?

When a document is laden with ARIA, most of that ARIA should be 
generated during run-time,
by the scripting environment, the UA, and/or the AT.


>
>>>> For instance, when a user presses down, on the button, the UA would
>>>> actually
>>>> set the aria-pressed property
>>>> if onmousedown does not run event.preventDefault(). There's precedent for
>>>> this with textarea css resize.
>>>>
>>>> 5.
>>>> Mozilla has gone ahead and allowed<input type="file">    to be completely
>>>> embedded, receiving .click() delegates.
>>>> <x-awesome-button role="button"
>>>> onclick="this.getElementsByTagName('file')[0].click()"><input type="file"
>>>> /></x-awesome-button>
>>>>
>>> I'm not sure I understand this point. Internally, browsers
>>> differentiate from generated click events on security-sensitive
>>> components and "real" click events. Are you suggesting we need
>>> something to help handle this case?
>>>
>> I meant only to show that there is now precedent for completely hiding an
>> interactive target element, such as input type="file".
>> That example should have had:<input type="file" style="display: none;" />.
>>
>> As I understand it, that kind of construct:<div role="button"><input
>> style="display: none;" /></div>,
>> is a preview of what Web Components will handle. It would help to handle
>> delegation of security-sensitive events.
>>
>> It'd really be helpful to be able to forward events, such as .click().
> In the WebKit implementation of shadow-DOM, we already handle such
> forwarding correctly. Events that bubble out do "appear" to have come
> from the component, not the item in the shadow DOM.

How does this work on a complex element, containing multiple roles?
It's important that event.target has an appropriate role.

-Charles

Received on Saturday, 3 September 2011 18:47:01 UTC