Namespaces and the Web (was: ARIA States and Properties Meeting)

Hi, Henri-

This is a response to some specific points you raise...

Henri Sivonen wrote (on 10/24/2007 7:56 AM):
> 
>> This means that either ARIA attributes have to be part of the core of 
>> XHTML, SVG, etc.,
> 
> No, the specs that define XHTML and SVG could make a normative reference 
> to an ARIA spec and refrain from defining aria-* attributes on their 
> own. There is no technical reason why spec organization and division 
> into namespaces (in the sense of Namespaces in XML) would have to be the 
> same.

Incorrect.  There are technical reasons, just not ones you feel are 
important.  There is a difference.

Without namespacing, there is no way to validate SVG content that uses 
ARIA, because at best, SVG UAs will simply ignore the extra attribute. 
You have argued that schema- and DTD-based validation can't indicate all 
violations of a spec, which is true; but it can indicate a *useful* 
subset of those violations.

It is useful for an author to know that they misspelled an attribute 
name; it is mysterious to them when they don't get the expected results, 
with no way to know why without scanning each character of code. 
Validation provides that.

It is useful for an author to know that they assigned the 
'multiselectable' property or 'pressed' state to a 'radio' role, and 
that those aren't supported for that role type.  Validation provides that.

SVG (or someone) could write a schema that merges SVG's and ARIA's 
schemas, but that goes pear-shaped when any changes or extensions of 
either language come out, and it only works for those 2 languages for 
that period of time.  Namespaces solves that problem in a way that works 
for all languages for any time.  It doesn't require someone who 
understands the intricacies of schemae to combine two languages; it 
requires only a simple declaration and prefix scheme.

In short, there are technical reasons (and even reasons of ease of 
authoring).  Whether they are sufficient to hold sway over other factors 
is another matter, but it is untrue to mistakenly claim there are not.


>> one of which is only available to official standards, because it 
>> cannot guarantee global uniqueness otherwise.
> 
> Global uniqueness is a red herring. Collisions with pre-existing HTML 
> and SVG attributes are the real technical concern for *Web* 
> accessibility. aria-* does not collide with pre-existing HTML or SVG 
> attributes, so collisions are not a problem with the aria-* scheme. 
> Collisions with attributes from *theoretical* *non-Web* languages aren't 
> a real technical concern for enabling *Web* accessibility--just like 
> making the id attribute in no namespace have ID semantics would have 
> worked just fine for Web languages and xml:id addresses a theoretical 
> non-Web problem.
> 
> When developing specs for the Web, we shouldn't let theoretical non-Web 
> concerns add complexity.

Do you consider set-top boxes as part of the Web?  What if they have 
network capability?  Internet capability?  Do you consider mobile phones 
as part of the Web?

If you answer "no", I think you are being short-sighted.  If you answer 
"yes", then you have to acknowledge that it's not "theoretical" or 
"non-Web".  There are already many UAs for both these classes of 
devices, and they do mix other XML syntaces into their content, and any 
answer that we arrive at must include them.  As I understand the charter 
of this group, it intends to make an XML serialization of HTML5, and 
would like to set that as the baseline for future XHTML work.  This is 
not theoretical, and it is not non-Web.  Those are rhetorical arguments 
that are of little bearing in a technical discussion.


I am *not* insisting that we have ARIA in its own namespace; I am 
insisting that we talk about it using facts, not political positions.


Regards-
-Doug Schepers
W3C Staff Contact, SVG, CDF, and WebAPI

Received on Wednesday, 24 October 2007 19:35:44 UTC