ARIA Coordination - PF, HTML, XHTML, SVG

 

RS Looking to get ARIA support in HTML/XHTML/SVG.

support in Dojo, Firefox, etc., but still a couple of issues.

some issues: namespaces in HTML, IE defects on attr selectors, triggering off ARIA states & properties. Would prefer something that doesn't use a colon.

can we come up with a more general solution to the problem?

(time out to find a relevant party)

DanC: Between 450-500 people have joined HTML WG since created earlier this year.

Level of chaos on list and wiki is high, but ARIA issues documented on wiki

Freaked out about implementation issues surfacing because it seems premature to be implementing

<DanC_lap> http://esw.w3.org/topic/HTML/ARIAIntegration ast edited 2007-10-10 13:05:56 by GregoryRosmaita

StevenP: XHTML2 WG is chartered to produce an XML application, and standard extension in XML is to use namespaces. Role attr can be used in multiple ways, including accessibility.

It's possible to apply, for example, checkbox role to a div.

<DanC_lap> ("unable" is strong; there's argument against)

My understanding is that HTML cannot adopt this mechanism.

ChrisL: We use XLink for linking. We don't care how it's done so long as it's well-formed. Just put it in the DOM and don't worry about rendering it.

ARIA mechanism is fine because we can just use it. Having a role for mini map to navigate a larger map is useful. We don't expect this role to be defined, but specialized implementers would want that. But collisions could occur without namespaces.

<ChrisL> Colin can be used in internet explorer. MS Office already generates "html" that uses multiple namespaces - v: for vml, mso: for office extensions

DougS: I agree with everybody. Namespaces is elegant solution. Colon causes problems in IE. Would be ideal to have the same syntax across languages. Would be difficult for authors to use aria:* in one place and aria-* in others.

Don't have a good solution.

<ChrisL> ... they use /: in css to get around the colon being special in css

SP: I don't believe there's a syntactic solution. But did occur to me that maybe the solution is to use XBL.

XBL allows you to use shadow trees. Then we wouldn't have to care that they're different across languages. Like adding a style sheet after the fact.

<DanC_lap> in my opening remars, pls include: DanC: I gather some implementors are likely to make decision soon, which concerns me because it's not clear that the ARIA schedule and requirements are clear

<anne> So FWIW, I agree XBL would be nice, but that's not implemented at all

<DanC_lap> Squatting on link relationship names, x-tokens, registries, and URI-based extensibility

<DanC_lap> Squatting on link relationship names, x-tokens, registries, and URI-based extensibili

DanC: x-* tokens are common conventions. My belief is that you can start with a standard URI, and can work on a standard process. If it doesn't reach the level of standardization, then you'll still have the convention.

<Zakim> ChrisL, you wanted to comment on the "IE ioncompatibility" argument

We used to fight this with rel, and then rel="nofollow", and we celebrated that. Confusing.

ChrisL: I find it hard to believe IE doesn't do colon namespaces. Can use

<anne> The hack you described for Selectors doesn't work at least for attribute values ChrisL

\: for colons

<ChrisL> thx anne

hsivonen: IE does something with the colon. What it does is different from the XML DOM.

In Opera, WebKit and Gecko, backslash has no meaning. So multiple ways to handle the colon.

With HTML5, design goal is that parsing should be as close as possible to legacy so that it works consistently. Since legacy browsers do differently, spec follows non-IE browsers.

Since there is no interop with colon, best way is to avoid colon.

<ChrisL> the legacy is not interoperable again

You can't change the legacy. If you introduce something yet different for HTML5, then you have a fourth option.

<DanC_lap> (Al, we're now into HTML versioning issues, which is a notoriously tricky issue in public-html [perhaps you already know that])

<oedipus> content should be browser-agnostic -- implementation decisions should not be made based on limitations of non-complying UAs

Opera tried namespaces in HTML and it didn't work out because of legacy content.

<ChrisL> correct labelling of html5 would allow all browesers, including ie, to correctly process colons and have a namespace plus local name, same as in xhtml

DougS: You didn't describe what problems there were.

anne: We don't want another doctype switch.

<ChrisL> right, it can't apply to *all* legacy content. better to correctly label html5

hsivonen: goal is that the DOM you get behaves the same in HTML5 and legacy browsers for parts of the language other than errors.

<ChrisL> its seems crazy to propogate a method that has already been stated not to work and not to be interoperable between ie and non-ie, and which ie won't change; and to propogate that to replace one that does work in existing browsers

There's no value to script writers to create two different mechanisms.

<ChrisL> but you *are* introducing a discrepancy

<anne> we're simply introducing new attributes...

If we have a script written for HTML5, same script should work in XHTML5.

<ChrisL> agreed, but there are two ways of having a script work the same in html5 and xhtml5

<ChrisL> ... and one of those ways breaks *everything else*

DanC: HTML WG decision-making procedure is just starting, so if you want an answer from us soon, you're stressing things.

<DanC_lap> ... especially a decision that's intertwingled with versioning

DougS: Things are being implemented presently.

DanC: As chair, no decisions have been made.

<DanC_lap> to clarify: the HTML WG as a whole has not made any design decisions.

DougS: anne, you said Opera doesn't want a switch, but IE clearly does. Saying there can't be one is not yet off the table.

anne: I'm saying that's our opinion.

<ChrisL> I agree with Dan that decisions have not been made, per process; I'm also hearing lots of claims that decisions can't be changed or that opinions will not be changed

hsivonen: I believe Mozilla position is the same.

<ChrisL> Anne and henris say 'no more switching'

<DanC_lap> yes, the HTML WG process has a fairly high level of chaos, true.

<ChrisL> Dave Hyatt came firmly in favour of a switching mechanism

DougS: I believe it's still open.

DougS: XBL could work if it were implemented. Mozilla doesn't support XBL2. Need something that works today.

<DanC_lap> "Dave Hyatt came firmly in favour of a switching mechanism" was what DougS said; let's please be more clear about attribution

<ChrisL> IE certainly needs a switching mechanism so they can not treat the old legacy (that they mostly madxe, from ms tools) differently

Rich: XBL is an enormous expectation of the browsers. Not that it's a bad idea.

<DanC_lap> (re things that are in e-mail already, pointers are welcome, but not everybody has read everything, and discussion can shed light on stuff that's already been said.)

Applications are being built today. People need access to this information. We have working examples, e.g., Dojo. But we want to make it easier. Need something that works in today's browsers, preferably easier in HTML5. Then want to look at SVG next.

<ChrisL> quoting from the html vision document "Also, as soon as there is a need for any extensibility, the XML serialization (with use of XML namespaces) gains an immediate practical advantage."

<ChrisL> http://www.w3.org/2007/03/vision

Raman: DanC made an important point re: no decisions being made. If PFWG expects a final decision on ARIA, we may be stressing things too much. But does PF need a firm answer on ARIA today? We designed ARIA to patch HTML 4. The point of HTML 5 is that people are writing HTML 4.

<oedipus> +1 to the "vision thing"

ARIA works on HTML 4 now. No need to be designing or hacking this for HTML5. There's still time to do this for HTML 4 now, and HTML5 later. We have apps using this now. Why do this now where angels fear... even looking in?

<ChrisL> pointer to dojo doing this?

<DanC_lap> yes, please, pointer to dojo doing this?

<MichaelC> anne, http://www.w3.org/WAI/PF/adaptable/HTML4/ explains HTML 4 implementation of ARIA

StevenP: Understand scripting issue is important. But Dojo supports it now, and toolkits are popular.

Can abstract this away.

<ChrisL> http://www.goodold.se/blog/tech/?p=12

Raman: No matter how this is done, it's one global replace to repair.

<ChrisL> quoting "Proper namespace support is one of the main reasons I fell for dojo. To avoid name collisions is far more important than writing the shortest statements."

hsivonen: Reason to rush this is that if ARIA support doesn't get into FF3/Opera9.5, then another generation is lost.

<anne> MichaelC, that's not really a realistic implementation imo, but ok

As for abstraction, if browsers do different things for scripting, you can abstract it in the library, but that's a fix for a problem, and there's no value to scripters to introduce these discrepancies to satisfy aesthetics or politics.

Rich: As a developer supporting ARIA, would rather set the attribute without having to use the colon. Cuts down on the code going down to the client if you can fix this problem.

Would be nice to consider having a dash equivalent to a colon.

DougS: Dash equal to colon would be very unrealistic.

<DanC_lap> FYI, the versioning stuff now has a home in the budding HTML WG tracker system http://www.w3.org/html/wg/tracker/issues/4

<Rich> scribe: Rich

<ChrisL> there are lots of hyphens in attributes. for example formatting properties

<ChrisL> font-style etc etc

Matt: My concern is that we can fix this in scripting so that scripters can use this. Most scripters have no clue how to do things accessibly
... scripters will come back to the browser developers asking why we need to do this additional work
... would like to take the gloves off and see how we can address this

<ChrisL> http://dojotoolkit.org/book/dojo-book-0-9/part-2-dijit/a11y/dojo-accessibility-strategy#implARIA

Raman: Firefox has an implementation already

<Zakim> DanC_lap, you wanted to ask hsivonen for estimated decision schedule for firefox 3

<ChrisL> http://dojotoolkit.org/book/dojo-book-0-9/part-2-dijit/a11y/dojo-accessibility-strategy#implARIA

DanC: henri, do you know about the Firefox schedule?

<ChrisL> see http://dojotoolkit.org/book/dojo-book-0-9/part-2-dijit/a11y/dojo-accessibility-strategy#implARIA

DanC: lag between dev and release?

AaronL: Can't give a firm answer. If we can decide before Christmas, then we have a good chance.

Rich: We do have aria-* already implemented.

AaronL: You can still use - in HTML, and : in SVG

<ChrisL> see for example http://tinyurl.com/2xtne5 on aria in dojo

Raman: for the record, colons do work in FF3.

and FF2

<ChrisL> dojo 1.0 shipped last week and uses xml namespaces. works in ff2 and ff3. hyphen might work in ff3 perhaps

DougS: What about Opera?

ChrisL: I think the answer is that XHTML is supported. If HTML5 isn't going to improve on the situation, then if you need accessibility, you should be using XHTML.

AaronL: Everyone that I know doing ARIA is doing text/html.

<ChrisL> aaron - yes, because shipping text/html for ie and app/xhtml for everyone else is a pain

DougS: Expected content authors for ARIA are presumably not newbies. Someone who's making a custom control is not a novice. They're capable of different syntaxes.

AaronL: There's a range from newbie all the way to custom widget. Raising the learning curve isn't helping.

<ChrisL> and we need to enable all points on that experience curve to use it. something that only works for light use and doesn't work for heavy lifting is not desirable

Al: We have people with different attitudes toward a standard format. We started out doing ARIA with the extensions available to us, but they were fairly general and open, and suitable for extension vocabularies in a small domain: chemistry, etc.

<ChrisL> al: work started using well proven extensibility mechanisms grounded in uri space so domain experts can develop their own vocabularies. but accessibility needs to be everywhere

Accessibility wants to be a part of the core. We may not have built it perfectly, but what's in ARIA 1 is a collection of terms that should interop with different host languages. It's a different beast.

<DanC_lap> (Al makes an argument parallel to my position on TAG/standardizedFieldValues; to echo it back: we already did the URI-based experiment; it's succeeding; time to make centralized short names.)

<ChrisL> in text/html, dom understands setattrributeNS and getattributeNS but the parser will not do that for you; you have to do it post parsing in script. that works in ff2

hsivonen: What works in FF2: if parsed from text/html, then setAttributeNS works from script, but the parser doesn't do that for you.

<ChrisL> no value for authors that they have to implement namespaces in xml themselves in script. parser should do this

<ChrisL> so the hyphen methods wont work in ff3 and will work in ff2

At w3.org is an IBM-authored document for working around with CSS/JS. Doesn't make any sense to do that to authors. Parser should do the right thing. What makes the most sense is to serialize it properly. aria-* is easiest way for authors. Need to do this as early as possible for browsers.

Concerned about documents being written in various doctypes, with scripts as modules.

<DanC_lap> (re "DTD for HTML", the HTML 5 spec treats DTDs and such as implementations rather than as part of the spec, and I don't expect the editors to change their mind on that.)

<oedipus> +1 compound documents are a VERY compelling reason to have 1 implementation solution

<ChrisL> I don't expect user agents to fetch external DTDs, ever

Raman: Wasn't advocating enable.js approach. In practice, role and state values come from script, not markup. Dynamic attributes need to change from script. And too complicated to do in markup. HTML5 will have better widget story. HTML 4 content will come through script.

hsivonen: XHTML attribs in SVG: doesn't make it easier for authors than having the aria: namespace in SVG. Only complicates things more.

ChrisL: Agree. But having to add hyphens is an extra burden.

<shepazu> DS: I agree with Henri on this point

hsivonen: Whole point of -* scheme is that no namespace processing is done, and DOM doesn't apply meaning to aria-*. So the XML stack doesn't know about it.
... Hasn't been explained what practical problem is being solved.
... If SVG takes attributes starting with aria-, there's no collision.

ChrisL: That's incorrect.

<DanC_lap> (TESTCASE note... would be nice to have a test for aria- in SVG and collect data on what implementations do, recorded in EARL)

In the SVG spec, you may not add attributes in the same namespace and expect SVG to handle it.

We would have to add aria to our namespace.

DougS: And if ARIA makes a change, we would have to add it to our spec.

<oedipus> DanC: would you like me to take your EARL suggestion to the ERT (evaluation and repair tools WG that wrote EARL) or is this something you are planning to do yourself?

<DanC_lap> (hmm... I'm not sure the cost of changing the SVG spec is really higher than the cost to authors of namespace declarations. I'd love to get some economics student to study it or something.)

AaronL: Having to do things through the DOM really isn't acceptable. Yes, possible, but not everyone is as sophisticated.

<anne> I don't see what the problem is with adding accessibility support to SVG, HTML, and XHTML without namespaces

<ChrisL> we would be willing ti add all of aria to the svg spec, if thats what it takes, but then we need to rev svg each time aria changes, and other groups will ask to have their stuff added too

When you have to teach ARIA, to people who usually don't want to do it, you want to make it as easy as possible.

<anne> Also, you have to define the interaction of namespaced attributes and languages anyway. Such as SVG does for XLink and SVG

<anne> Otherwise SVG would not have to talk about XLink at all for instance...

<ChrisL> ... if its aria:whatever then there is no spec change needed and it already works

Only the people in this room really care about this. Most people are just trying to solve real problems.

StevenP: We're also talking about MathML, SMIL, etc. By having a standard extensibility mechanism, someone authoring can just use it and create a UA that does stuff with it.

<Zakim> hsivonen, you wanted to say spec org problem not a technical problem

hsivonen: Doug's issue isn't a technical issue. When Unicode comes out with an updated version, consumers can use the new characters. SVG could point to an updating spec. When you have a schema, you can put ARIA in a RELAX-NG schema as an include.

It's a fallacy to think that the specifiers of the language have to produce a schema.

<oedipus> examples of xml-based specialized domain markup that may need ARIA: CellML: http://www.cellml.org/ -- MAGE (MicroArray and Gene Expression ML): http://www.mged.org/Workgroups/MAGE/mage.html

Even if you wanted to make it part of the spec deliverable, you could add that include file.

DougS: I still want to keep underscore on the table. Dash is overloaded. Having underscore gives us the option to do some namespace-like thing in the future.

<ChrisL> I'm reading http://www.w3.org/TR/aria-role/ and see that the role attribute is **not in a namespace anyway** so I wonder what in fact we are discussing

<Zakim> DanC_lap, you wanted to say I'm not at all suprised to re-visit the level of consensus around the XML namespaces mechanism

DanC: I'm not surprised about namespace argument. It was contentious throughout the process. Angry bloggers, etc.

ChrisL: If all else fails, read the spec. None of the attributes are namespaced. What are we discussing here? The attribute values.

Rich: This is the states document.

<oedipus> http://www.w3.org/TR/aria-state/

ChrisL: It would be easy to add state to RELAX-NG schema for SVG.

<DanC_lap> just about 2.1.1.2 in /TR/aria-state is on the projector

<DanC_lap> just above

Can add a line of NVDL to point to the right schema.

It's already valid.

DougS: What if you change the colon to a dash?

ChrisL: Then you're screwed.

Al: It's clear that if you're using namespaces, can use namespace-based dispatching for validation. But can you write RELAX-NG so it imports by a match pattern of aria-*?

<DanC_lap> (indeed, we need to keep in mind the world-wide cost to authors when considering the cost of spec updates. and there are interactions between them, involving the value to the world of a trusted entity like W3C)

<anne> I would also like to say that making design decisions based on limitations of schema's seems silly at best

hsivonen: You can't use a wildcard in the local name. However, you can make a separate include that enumerates aria-* attributes at the time the include was authored, and update the include.

<Zakim> hsivonen, you wanted to say ease of authoring should override ease of using NVDL

hsivonen: You can still write RELAX-NG for aria-*. Can also write SAX code to deal with this. Validation technology shouldn't affect authoring.

ChrisL: We already had someone altering the SVG spec. That's why we have these rules.

Al: Next steps?

<DanC_lap> (please excuse me; I'm expected elsewhere now.)

DougS: role attribute module in SVG would still need colon. Needs to be resolved.

Al: HTML WG will consider on Saturday.

<ChrisL> the problem is "The document MUST conform to the constraints expressed in Appendix A - DTD Implementation, combined with the constraints expressed in its host language implementation."

DougS: I propose that in SVG spec we would normatively reference XHTML module to rely on it for semantics.

ChrisL: That could be a more focused discussion. We'll report back.

<oedipus> +1 to DougS' normative reference of XHTML Role module for semantics in SVG

Rich: That leaves ARIA modules.

Al: Agree that another spec is published controlling aria* attributes, and normatively referenced by conforming specs?

Raman: Only risk is that we have two namespacing mechanisms 5 years from now.

<ChrisL> I suggest that Steve, Doug myself and any other interested parties discuss the xhtml-role conformance requirements

DougS: SVG can talk about this later today.

StevenP: Can discuss this in Hypertext CG.