On 9/2/11 3:00 PM, Alex Russell wrote:
On Fri, Sep 2, 2011 at 1:40 PM, Charles Pritchard<ch...@jumis.com> wrote:
On 9/2/11 12:10 PM, Alex Russell wrote:
Since Dimitri has already said everything I would, and better, I just
want to very quickly second his point about where we are today vs.
where we fear we might be: non-trivial apps have *already* given up on
HTML. Suggesting that there's an un-semantic future that will be
*caused* by the component model is to fight a battle that's already
lost.
The only question we need to answer now is: how do we repair the
situation?
In spending the last 9 months thinking and working through the issues
Dimitri presents below, our strongest theory now is that there *is* a
market for semantics, that it *does* organize around winners (e.g.,
Microformats), and that we're missing a mechanism for more directly
allowing authors to express their intent at app construction time in
ways that don't either pull them fully out of markup/html (see:
Closure, GWT, etc.).
Instead of imagining total anarchy, imagine a world where something
like jquery-for-WebComponents comes along: a "winner" toolkit that a
statistically significant fraction of the web uses. Once that intent
is in markup and not code, it helps us set the agenda for the next
round of HTML's evolution.
Alex, Dimitri:
1.
I've found ARIA to be an appropriate microformat for new components.
That is what it was designed for, after all.
ARIA is how we envision components developed in this world will
communicate with assistive technology. Nothing in Web Components is
designed to supplant or replace it.
I suggest looking at ARIA as more than a method for communicating with
assistive technology.
It's a means for communicating UI component states.
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.
How should ATs be notified/detect that there is a shadow DOM?
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?
"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.
It seems like "event.preventDefault()" is an important hook to keep in mind.
Is Web Components, in some manner, calling for a registerDefault method?
2.
ARIA 1.0 may not be sufficient, but I do think it's been designed to be
forward compatible, and "meta" compatible with HTML5.
I can, for instance, use: role="spreadsheet grid" even though "spreadsheet"
is not an ARIA 1.0 role; thus forward compatibility, and semantic lenience.
Nothing we're doing reduces the utility or need for ARIA. It works
*great* with these component types, and to the extent that we can
align them, I'm excited by how much easier it's going to be for
component authors to be, allowing them to focus on concerns like a11y
instead of "how do I get this thing to fly in the first place?"
I agree, I think it'll work great, and be easier.
I'm hopeful there will be lessons to apply to an ARIA 1.1 spec.
ARIA 1.0 has gone through a lot of work, but it hasn't gone through the
rugged real-world testing of hundreds of thousands of programmers
developing custom components.
Authoring a spreadsheet component in ARIA is a mixed-bag. There are
great items, lots of expressiveness, but also some areas that feel
lacking. The spreadsheet widget metaphor has been around a long time,
but it's open-ended in ways, much like rich text editing, and so, only
by authoring, do we get an idea of the vocabulary. contentEditable
could be wrapped as a web component. Rich text styles have long been in
accessibility interfaces.
3.
Let's look at how jquery "fails" to support ARIA, though it's an easy fix.
Many jquery widgets have ARIA hooks in place. But what about jquery itself?
$('#div').attr('role', 'button') vs $('#div').role('button');
$('#div').attr('aria-pressed','true') vs $('div').pressed();
Those later examples are what first class ARIA support would look like, in a
JS framework.
The widgets themselves are the pattern that we'd like to bolster. What
low-level frameworks do is unchanged by any of this.
Makes sense.
Low-level frameworks should pick up some of these semantics, so they may
more easily work with Web Components and other ARIA-laden structures.
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'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.
How about: <x-awesome-button becomes="button">; incorporating both ARIA
and HTML/CSS default events.
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">.
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().
Consider a "target" attribute, in addition to "becomes":
<div becomes="file button" target="input"><input style="display: none;"
type="file" /></div>
That's certainly easier than setting up all of the click and focus handlers.
It does have the negative effect of disabling file on non-supporting
non-scripted environments.
Something like this would still work, for such targets:
<div becomes="file button" target="input" style="content: ''
replaced;"><input type="file" /></div>
If Web Components were integrated with CSS generated content, the
content style could be improved:
<div becomes="file button" target="input" style="content:
component;"><input type="file" /></div>
When the subtree is simple, the markup could be as well:
<div becomes="file"><input type="file" /></div>
At that point, we have reached similar proposals/solutions to these use
cases, relying on the existing CSS generated content spec.
<input type="file" style="content: url('myimage.png') replaced;" />
-Charles
