Re: Discussing ARIA in HTML5 integration

On Apr 10, 2008, at 01:45, Gregory J. Rosmaita wrote:
> for the record, i never stated as an individual or a member of any
> particular working or interest group, that PF is ignoring HTML5;
> i don't speak for any working group or behalf of any working group,
> nor do i claim to do so; i DID, however, at the meeting from which
> henri drew his quote (which was accredited to me, but is a scribe's
> encapsulation of what i said),

I understand things get misscribed. I probably shouldn't have quoted  
the second line since it merely distracts from my point. (My point  
being that there's has been no invitation to a meeting recently on the  
communication channels that "HTML5 people" follow, so it is rather  
natural that no one showed up.)

> state that since PF has had no success
> in getting everyone together in one place (virtual or physical) to
> discuss the various suggestions and concerns as to how ARIA can be
> integrated into HTML5,

Isn't it natural that there's no success in getting HTML WG  
participants to come to the one place if there hasn't been an  
invitation on public-html lately?

> PF was redoubling its internal efforts to ensure
> that its house was in order as regards ARIA 1.0 so as to ensure that  
> it
> is tight enough and clear enough to pass Last Call without any major
> hurdles as to the consistency and clearness of the specification and
> its use

I think setting passing Last Call as a goal misses the point. I think  
the goal should be getting interoperable browsers shipped so that they  
address the use cases ARIA 1.0 is meant to address and that they are  
addressed in a sustainable way. (Likewise, focusing on an expected  
Recommendation due date for HTML 5 misses the point.) By sustainable I  
mean that the solutions still work when authorship shifts towards  
casual authors from specialists and when new products enter the market.

It seems to me that considering ARIA in the context of text/html  
(which obviously will be the most common format where ARIA will be  
used) is crucial for assessing whether ARIA is tight and clear enough.  
(I think it currently isn't considering how many feedback items I  
found about processing model issues since late last month.)

> and, what i said at last week's HTML WG telecon was that ARIA 1.0 is
> needed today and yesterday, and that embedding ARIA in HTML5 test
> cases is a non sequitur, because:
>
> a) ARIA 1.0 is for today and yesterday's web;
>
> b) that PF asked the HTML WG for native accessibility features to be
> incorporated into HTML5 to the fullest extent possible, but in the
> interim -- while such mechanisms are being developed in collaboration
> between the HTML WG and pertinent WAI working groups -- ARIA will be
> needed for today's script-heavy, semantically strapped web, as well
> as for the evolving web

I think you are too focused on 4 vs. 5 here, and an assumption that  
ARIA gets implemented before 5--that there's a clear "interim".  
Today's and yesterday's Web is neither 4 nor 5. Today's Web is de  
facto defined by existing content and what browsers implement. De  
jure, ARIA is invalid in HTML4 and, for the moment at least, in HTML5  
too. So thinking in terms of 4 and 5 misses the point.

What should be considered is where existing content and browsers are  
now. (For purposes of browser now, consider the versions about to  
ship--not the latest official releases.) So if existing content can't  
do X in browsers now and you want them to do X, we should consider  
what long-term solution we want for X and what kind of short-term  
solution could achieve X quickly. If it turns out that the long-term  
solution is about as simple to implement as the short-term solution,  
doing both short-term first and long-term second becomes pointless and  
it would be smarter to implement the long-term solution up front.

When assessing this, the focus should be on what it takes to implement  
the proposed solutions for a given use case. You shouldn't assume that  
what goes into the ARIA spec will be implemented first and what goes  
in the HTML 5 spec will be implemented in far-away future. Browsers  
are already implementing parts of HTML 5 and at the same time are not  
implementing all of ARIA as currently drafted.

So really, it is about doing things in text/html with browser support.  
Spec REC track status is a distraction.

More concretely: XBL2 and <aside> have dramatically different  
implementation characteristics and deployment strategy  
characteristics. You can go straight to <aside> even if market  
considerations don't allow straight migration to XBL2. Therefore, you  
shouldn't reject all long-term solutions because some of them are hard.

It may be that the PFWG ends up considering the Firefox 2 legacy too  
limiting for <aside>, but just dismissing it because HTML 5 is far  
from REC or not "yesterday's Web" would miss the point.

> c) that, given its nature and intent, ARIA 1.0 cannot be held up by an
> evolving and unstable technology;

What really matters is getting interoperable implementations. That's  
what is holding back ARIA. HTML 5 isn't holding it back. Whenever a  
given Web platform feature gets interoperably implemented, it becomes  
de facto stable no matter what the REC track status of the document  
defining it. On the other hand, a spec that hasn't been interoperably  
implemented shouldn't really be considered stable no matter what its  
REC track status. So if you get a piece of HTML 5 interoperably  
implemented, that piece is stable. Until you have gotten a piece of  
ARIA interoperably implemented, that piece of ARIA shouldn't be  
considered stable.

The ARIA spec needs to get to the point where if you have N browsers  
implementing it, browser N+1 can be implemented per spec (not by  
reverse engineering the first N browsers) and have it Just Work with  
content written for the first N browsers.

More concretely, the ARIA spec isn't ready to become a REC if Opera  
9.5 and IE8 have to be implemented by reverse engineering Firefox or  
by reading Mozilla implementation notes (as opposed to coding to the  
spec) or if WebKit's (presumably upcoming at some point) ARIA support  
will have to be implemented by reverse engineering all of those three.

> d) that HTML5 support amongst UA implementors varies; amongst  
> assistive
> technologies it is nonexistent

When AT gets information via an accessibility API (as opposed to  
mining the internal data structures of a particular browser), it  
shouldn't matter to the AT if the browser is mapping HTML 5 or ARIA  
features to the accessibility API.

> (and in some cases, perhaps, impossible);

Could you, please, elaborate?

> e) that the overwhelming mass of content on the web is HTML 4x and
> XHTML 1.0 (roughly speaking) plus scripted slash dynamic content --
> this is the content to which ARIA 1.0 needs to be applied, and has  
> needed
> to be applied for (at least) the past 6 to 8 years;

The overwhelming mass is text/html. HTML 5 defines processing for text/ 
html. ARIA 1.0 is invalid in HTML 4 and XHTML 1.0 and you can't change  
that, but focusing on de jure spec numbers misses the point. (You can  
still change what is valid HTML 5.)

> f) HTML 4x/XHTML 1.0 contains several mechanisms (such as LONGDESC
> and the headers/id association for TABLE) which HTML5 currently does
> NOT support,

HTML5 now has headers/id. So far research suggests that longdesc has  
failed in practice. (That is, it has been said that longdesc is  
*meant* to help accessibility, but it hasn't been shown that it  
*actually* helps on average.)

> but for which there is extant support in extant assistive
> technologies as well as in ARIA, but that the ARIA mechanisms are not
> direct corallaries to their HTML5 equivalents -- in some instances,
> "describedby" could provide a long descriptor, in others it cannot --

When can describedby not provide a descriptor?

When HTML 5 lacks functionality that ARIA provides, it would be good  
to know what use cases HTML 5 fails to cater for.

> g) that it is necessary to find a way to integrate current and future
> ARIA markup into generalized as well as specialized markup languages;

For the Web context, though, ARIA needs to integrate with HTML and  
SVG--the two languages whose existing content may need accessibility  
retrofitting. It would be unfortunate if overgeneralizing of ARIA to  
work in non-Web contexts made ARIA more complex than necessary for Web  
authors.

> especially HTML5, if the accessibility mechanisms defined in HTML 4x
> are not retained or improved, and that PF and other WAI groups have
> expressed an active interest in working with the HTML WG on ensuring
> that mechanisms retained, changed or adapted from HTML 4x are superior
> -- as well as implementable -- solutions which would (if the native 
> markup is used correctly) obviate the need for several aspects of
> ARIA 1.0; however, since such an obsolescence is a panglossian view of
> the future of HTML authoring, ARIA must have a means of being included
> slash supported (an HTML + ARIA profile) now and in the future, not  
> just
> to accommodate improvements in ARIA and the addressing as yet  
> unforseen
> problems and obstacles that may arise between the issuance of ARIA 1.0
> and the coalescence of HTML5

I'm not sure that I parsed the last part of the last sentence  
correctly, but there are currently a number of foreseeable issues with  
ARIA in HTML 5 (aria-level, aria-setsize, landmarks, XSD dependency,  
etc. off the top of my head). The sooner unforeseen issues become  
foreseeable, the better.

> we spent almost 45 minutes on the HTML WG call on this specific topic,
> in an attempt (at least on my part) to clear some basic misconceptions
> as to:
[...]

Even if there had been one more participant on the call, there'd still  
have been hundreds of HTML WG participants whose [presumed]  
misconceptions would not have been cleared. Hopefully clearing the  
misconceptions on the mailing list(s) has a better reach.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Thursday, 10 April 2008 09:22:14 UTC