Re: conformance checker for HTML+ARIA?

On Sep 30, 2008, at 11:24, Steven Faulkner wrote:

> Members of the development community are asking for a way to check
> their HTML+ ARIA documents for conformance and one that does can be
> used to check all flavours of (x)HTML without all ARIA associated code
> being flagged as non conformant.

Which is correct behavior, because ARIA markup is not valid according  
to HTML 4.01 or XHTML 1.0. ARIA markup isn't valid according to the  
current HTML5 draft, either, but HTML5 isn't done yet.

> The experimental HTML5+ARIA checker developed by Henri Sivonen does  
> this, but it is limited to the HTML5 doctype.

I'm not convinced that the HTML5 doctype is a real problem in itself,  
although I can see how it is problematic that HTML5 as currently  
drafted doesn't make upgrading existing markup templates smooth by  
obsoleting some popular attributes (such as the border attribute on  
<img> and align attribute on <td>).

> It also flags issues based on a set of rules, defined by Henri, on  
> what constitutes conformant HTML5+ARIA (for example role="document"  
> is not allowed) [2].

I made up rules myself, because neither the ARIA spec nor the HTML5  
spec was addressing ARIA in HTML integration in a satisfactory way.  
The rules I made up were meant as an executable proposal to move this  
issue forward. I got some feedback from individual PFWG participants,  
but I didn't get feedback that could be considered as indication of  
what PFWG intends to do about document conformance in the context of a  
concrete host language.

(Aside: After I made the executable proposal about HTML5+ARIA, I have  
answered to inquiries about SVG+ARIA saying that it doesn't make sense  
for me to give SVG+ARIA the same treatment of me making stuff up  
before getting some sort of indication whether the PFWG agrees that  
the general approach I proposed makes sense.)

> Can we build ARIA checking into the W3C validator so that ARIA  
> conformance can be checked seemlessly with HTML whatever the version?

HTML 2.0, HTML 3.2 and HTML 4.01 are what they are, and they don't  
allow ARIA markup--just like they don't allow <video>.

Can we solve the practical problem here without backporting newer  
markup features piecemeal and pretending (via "errata" or otherwise)  
that old HTML specs allowed something they didn't allow? Surely the  
label "HTML5" vs. "HTML 4" in the validator UI isn't the practical  
problem?

On Sep 30, 2008, at 12:26, David Dorward wrote:

> The HTML Working Group is chartered to "maintain and produce  
> incremental
> revisions to the HTML specification"[1], which I would imagine HTML  
> 4.01
> + ARIA would fall under. I imagine you would raise the matter with  
> them
> and see if they would be willing to work with the WAI to publish a  
> small
> Recommendation which makes reference to ARIA and HTML 4.01, defines a
> Doctype and includes a DTD.

HTML 4.01 is so broken in so many ways that I think it doesn't make  
sense to divert resources to put out individual fires.

A bit over a year ago, I was advised against putting effort into  
maintaining the HTML 4.01 and XHTML 1.0 functionality of Validator.nu.  
I didn't take the advice back then, which is regrettable, because now  
people ask me to put more and more effort into that dead end instead  
of the users just using the HTML5.

That is, it seems that people recognize that Validator.nu offers  
better technology (datatype checking, etc.) compared to DTD-based  
validation but, yet, shy away from HTML5 validation and instead want  
the same improvements in schemas that are labeled HTML 4.01 or XHTML  
1.0.

Instead of changing the HTML 4.01 and XHTML 1.0 schemas to be even  
further away from what those specs (vaguely) said while keeping them  
labeled HTML 4.01 and XHTML 1.0 for marketing reasons, I would prefer  
to find out what makes the HTML5 definition of validity impractical  
for authors, remove those blockers and then talk about HTML5  
validation instead of pretending that HTML 4 validation changed to  
include new stuff.

If we make one-off HTML 4 + Foo validation targets, but where do we  
stop? Should we also have an HTML 4 + <canvas> validation target and  
an HTML 4 + <video> validation target?

On Sep 30, 2008, at 11:44, David Dorward wrote:

> Steven Faulkner wrote:
>> Can we build ARIA checking into the W3C validator so that ARIA
>> conformance can be checked seemlessly with HTML whatever the version?
>>
> That wouldn't really make sense. It would be more logical to create an
> HTML 4 + ARIA DTD and validate against that.

Such a DTD could have holes that ARIA could drive through with error  
messages removed, but DTDs are inadequate for actually validating  
ARIA--i.e. detecting ARIA errors.

>> People seem to want a form of checking  provided by the W3C that will
>> tell them (for example) that their HTML code is valid and their ARIA
>> code is valid.
>>
> If it has ARIA in it, then their HTML (by any current W3C  
> recommendation
> that I know of) isn't valid.

Right.

> You can't fix this problem at the tool level, you need to address it  
> at the standards level.

Exactly. Asking people to produce the tools when the relevant working  
groups don't work jointly on an actual normative conformance  
definition doesn't really make sense. Or it makes sense on the  
prototyping level but then what you get is the validator developer  
making stuff up.

On Sep 30, 2008, at 12:25, Gez Lemon wrote:

> It doesn't resolve the whole issue of ensuring that ARIA is used
> correctly with a native markup language, but if the ARIA specification
> is available in a machine readable format (such as what attribute
> values are valid for a particular attribute, and what attributes can
> be used with particular roles in RDF), we could build a basic
> validator to ensure at least the ARIA part is used according to its
> specification.

In my experience, the RDF definition was not useful when implementing  
the HTML5+ARIA prototype. I looked at the English prose and the tables  
instead.

On Sep 30, 2008, at 12:38, Jason White wrote:

> Yes, but unless the validator includes a Javascript interpreter and  
> a DOM
> implementation, all that can be checked are the Aria attributes of the
> document prior to the execution of scripts that modify it.
>
> Anything involving live regions or Javascript functions that change  
> states or
> properties would largely escape any lesser validator. Maybe the  
> validator
> needs to be written as a user agent extension that can verify  
> correctness as
> changes are made.

The validator doesn't need to run in the same process as the browser.  
It would be sufficient for a browser to serialize a snapshot of the  
DOM and send it over to another process for validation (e.g. over  
HTTP). Currently, one can approximate this with bookmarklets and  
Validator.nu. However, there is a problem that currently Validator.nu  
supports input in the text/html and XML serializations, but neither of  
those can express all the possible DOM trees, so to make things work  
for all possible DOMs, a new format and a SAX parser (in Java) for it  
on the Validator.nu side and a serializer in JavaScript for the  
browser side would be needed.

I have gotten inquiries about putting Validator.nu inside the browser  
process. I think that embedding a JVM in the browser process would be  
unnecessarily heavyweight. If someone wishes to pursue the in-process  
path with Validator.nu, I suggest using the compiler from Google Web  
Toolkit as a means of taking Java code and loading it onto the  
JavaScript VM of the target browser.

On Sep 30, 2008, at 14:10, Michael(tm) Smith wrote:

> I would think it'd be doable to add support in validator.nu
> experimental support for validating XHTML 1.0 and HTML 4.01
> documents containing ARIA markup.

It's possible to backport the ARIA stuff to the legacy schemas, but  
wouldn't it make more sense to forward port this stuff from HTML4 that  
keeps people from upgrading to HTML5 as their validation target?

> But I think it might be worthwhile to have a discussion with Henri  
> about whether those rules can or should be adjusted.

They can be adjusted. I was trying to poke the relevant working groups  
into saying how by showing an executable proposal.

> And/or we should discuss the idea of actually
> defining a spec for HTML 4.01 + ARIA, without reference to DTDs or
> perhaps without reference to any normative formal schema language
> at all.

I think we should instead put that effort into producing proper spec  
text defining conformance criteria for HTML5 + ARIA.

On Sep 30, 2008, at 14:22, David Dorward wrote:

> Michael(tm) Smith wrote:
>> That said, there's nothing blocking anybody interested in pursuing
>> the idea of producing a DTD for HTML 4.01 + ARIA and negotiating
>> with the validator.w3.org maintainers to add support for it.
> A DTD is a DTD. The validator works with DTDs, explicit support  
> doesn't
> need to be added. (Although, if its popular, it might be worth  
> adding it
> to the local catalogue (for speed) and the list of possible Doctype
> overrides).

Aside: Validator.nu allows user-provided RELAX NG and Schematron  
schemata.

On Sep 30, 2008, at 15:07, Aaron M Leventhal wrote:

> We do need a solution soon. This keeps coming up.
>
> I think W3C should drive this, since developers want the official  
> W3C stamp of approval.

Perhaps past emphasis on a W3C stamp of approval is part of the  
problem.His

> W3C can use a multi-pronged solution:
> 1. Short term: create new DTD and ask W3C to host it. It can be  
> considered "beta" for now.  It needs to include HTML 4 + tabindex  
> changes (allow negative numbers and on any element) + WAI-ARIA.
> 2. Medium term: DTD's are of limited value, and W3C can utilize  
> something that provides more in-depth checking. Perhaps  
> Validator.nu, but certainly at least looking at Henri's approach

The W3C is already hosting an instance of the Validator.nu software as  
a back end to a development version of the W3C Validator.

If you use the HTML5 doctype, you can get the same ARIA validation at http://qa-dev.w3.org/wmvs/HEAD/ 
  that you can get at http://html5.validator.nu/.

Why promote a less expressive DTD approach?

> Getting around validation by inserting content via script is  
> happening. I'm seeing developers recommend that ARIA is inserted  
> dynamically onload, just for that reason. Seems not to be useful.

Agreed.

On Sep 30, 2008, at 15:39, Michael(tm) Smith wrote:

> I'd suspect that the
> difficult part is getting agreement about what exactly the
> specific validity constraints in the DTD should be. I mean, I get
> the impression from the message that Steven cited that there's not
> agreement on the schema that Henri made.

Right. The problem of the spec missing can't be fixed by switching to  
legacy validation technology. :-)

>

Furthermore, trying to get the W3C Validator to add a new DTD would  
presumably involve putting a non-standard doctype on the documents to  
be validated. If authors were willing to do that, why wouldn't they be  
willing to use the doctype <!DOCTYPE html> if the validity definition  
of HTML5 were tweaked along the lines I suggested in
http://lists.w3.org/Archives/Public/public-html/2008Aug/0958.html

On Sep 30, 2008, at 16:11, Michael(tm) Smith wrote:

> I think having a normative spec for ARIA is HTML 5 is absolutely  
> something that the HTML WG needs to produce.

Hopefully together with the PFWG.

> But having a spec of HTML 4.01 + ARIA is not.

Agreed.

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

Received on Tuesday, 30 September 2008 15:20:33 UTC