- From: Al Gilman <Alfred.S.Gilman@IEEE.org>
- Date: Tue, 6 Nov 2007 21:38:00 -0500
- To: public-html@w3.org, public-xhtml2@w3.org, w3c-html-cg@w3.org, w3c-wai-pf@w3.org, www-svg@w3.org
Thank you all for joining today's joint session on embedding WAI-ARIA markup
in host languages.
DRAFT minutes are available at
http://www.w3.org/2007/11/06-aria-minutes.html
..and below as text.
Al
--
ARIA Coordination - PF, HTML, XHTML, SVG
6 Nov 2007
See also: [2]IRC log
[2] http://www.w3.org/2007/11/06-aria-irc
Attendees
Present
Regrets
Chair
Al_Gilman
Scribe
Rich, Matt, mattSCR
Contents
* [3]Topics
* [4]Summary of Action Items
_________________________________________________________
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> [5]http://esw.w3.org/topic/HTML/ARIAIntegration ast
edited 2007-10-10 13:05:56 by GregoryRosmaita
[5] http://esw.w3.org/topic/HTML/ARIAIntegration
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> [6]Squatting on link relationship names, x-tokens,
registries, and URI-based extensibili
[6] http://www.w3.org/2001/tag/group/track/issues/51
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> [7]http://www.w3.org/2007/03/vision
[7] 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, [8]http://www.w3.org/WAI/PF/adaptable/HTML4/
explains HTML 4 implementation of ARIA
[8] http://www.w3.org/WAI/PF/adaptable/HTML4/
StevenP: Understand scripting issue is important. But Dojo supports
it now, and toolkits are popular.
Can abstract this away.
<ChrisL> [9]http://www.goodold.se/blog/tech/?p=12
[9] 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
[10]http://www.w3.org/html/wg/tracker/issues/4
[10] 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>
[11]http://dojotoolkit.org/book/dojo-book-0-9/part-2-dijit/a11y/dojo
-accessibility-strategy#implARIA
[11]
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>
[12]http://dojotoolkit.org/book/dojo-book-0-9/part-2-dijit/a11y/dojo
-accessibility-strategy#implARIA
[12]
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
[13]http://dojotoolkit.org/book/dojo-book-0-9/part-2-dijit/a11y/dojo
-accessibility-strategy#implARIA
[13]
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 [14]http://tinyurl.com/2xtne5 on aria in
dojo
[14] http://tinyurl.com/2xtne5
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: [15]http://www.cellml.org/ -- MAGE (MicroArray
and Gene Expression ML):
[16]http://www.mged.org/Workgroups/MAGE/mage.html
[15] http://www.cellml.org/
[16] 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 [17]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
[17] http://www.w3.org/TR/aria-role/
<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> [18]http://www.w3.org/TR/aria-state/
[18] 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.
<MichaelC> meeting: ARIA Coordination - PF, HTML, XHTML, SVG
Summary of Action Items
[End of minutes]
_________________________________________________________
Minutes formatted by David Booth's [19]scribe.perl version 1.128
([20]CVS log)
$Date: 2007/11/06 22:25:06 $
[19] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[20] http://dev.w3.org/cvsweb/2002/scribe/
Received on Wednesday, 7 November 2007 02:38:35 UTC