DRAFT minutes of joint session on ARIA embedding 6 November 2007

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:32 UTC