Re: Invitation to the TAG to provide feedback on HTML5

On the accessibility thread,  I think now is the right time to
sanitize aria specified attributes with the various other UI
technologies floating around in HTML.  
here is an example: 

The following is simply bizarre and should be rationalized
between now and last call:

<input type=checkbox checked>

vs

<span role="aria-checkbox" aria-checked="true"> 
Putting aside why people do bizarre  things like turning spans
into checkboxes, I really think the above markup in order to be
sane to authors needs to look like

<span type=checkbox checked>

The same comment applies pretty much down the line with respect
to the rest of ARIA --- so though a lot of breath has been spent
on the "right" delimiter AKA dash the colon --- I think there is
more value in rationalizing the various UI aspects of HTML5 so as
to not need something like ARIA   for HTML5 documents. ARIA
properties might still be needed for HTML4 content -- but since
one is "not supposed to be able to tell" whether a document is
HTML4 or HTML5 (my personal opinion on versioning might say
otherwwise)--
I think we're creating a bizarrely messy situation where the same
information bit is being duplicated between ARIA attributes and
HTML5 attrbutes --- personally I'd like  the author  to  be able
to express a binary bit --- checked vs unchecked -- with one
attribute -- not several:-)

Ian Hickson writes:
 > 
 > On Wed, 21 May 2008, Dan Connolly wrote:
 > > Ian Hickson wrote:
 > > > 
 > > > It has come to my attention that the TAG prefers explicit requests for 
 > > > review rather than considering itself invited along with everyone else 
 > > > when a public draft is written,
 > > 
 > > Well, we're happy to look at specific architectural issues in any 
 > > work-in-progress in and around W3C, but otherwise, we don't expect 
 > > anything beyond being invited along with everyone else. And we don't 
 > > typically review specs -- especially specs as large as the HTML 5 draft 
 > > -- unless we're aware of architectural issues.
 > 
 > Ah, interesting. In that case let me ask for review for the following 
 > areas that are introducing major architectural features:
 > 
 >  * The use of the DOM as a basis for defining the language
 > 
 >  * The concept of browsing contexts
 > 
 >  * The distinction between Ua requirements and authoring requirements
 > 
 >  * The use of imperative definitions rather than abstract definitions with 
 >    the requirement of black-box equivalence in implementations
 > 
 >  * The new content model concepts (replacing HTML4's block and inline 
 >    concepts)
 > 
 >  * The focus on accessibility as a built-in concept for new features (such 
 >    as irrelevant="", <progress>, etc) instead of an add-on (like alt='').
 > 
 >  * The focus on defining the semantics in detail (e.g. the outline 
 >    algorithm, replacing the vague semantics in HTML4).
 > 
 >  * <event-source>
 > 
 >  * <datagrid>
 > 
 >  * <menu>/<command>
 > 
 >  * Origin
 > 
 >  * Offline Web application caches
 > 
 >  * The definition of the browsing context "navigation" algorithm and the 
 >    related session history traversal algorithms
 > 
 >  * The content-type sniffing and character encoding sniffing
 > 
 >  * The very explicit definition of a parser
 > 
 >  * The two structured storage features
 > 
 >  * The contentEditable feature and the UndoManager feature
 > 
 >  * The Drag and Drop and Copy and Paste architecture
 > 
 >  * postMessage
 > 
 >  * The new sandboxing features for <iframe>
 > 
 > I'm sorry the list is so long, but HTML5 really does introduce a lot of 
 > major new architectural concepts. I would not want the TAG to feel like 
 > these concepts came out of nowhere next year when we finally go to Last 
 > Call, as happened with the ARIA issue -- it may be very, very hard to make 
 > changes at that point, since implementations are developing at the same 
 > time as the spec, and it would be sad if the TAG's collective vast 
 > experience was to end up being ignored because we didn't ask for feedback 
 > soon enough.
 > 
 > Any input would be very welcome.
 > 
 > Cheers,
 > -- 
 > Ian Hickson               U+1047E                )\._.,--....,'``.    fL
 > http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
 > Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

-- 
Best Regards,
--raman

Title:  Research Scientist      
Email:  raman@google.com
WWW:    http://emacspeak.sf.net/raman/
Google: tv+raman 
GTalk:  raman@google.com, tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc

Received on Wednesday, 21 May 2008 23:11:41 UTC