Minutes: May 21, 2015 WAI-PF ARIA Caucus (Updated to cover DPUB ARIA module)

Link: http://www.w3.org/2015/05/21-aria-minutes.html

Plain text follows:

    [1]W3C

       [1] http://www.w3.org/

                                - DRAFT -

            Protocols and Formats Working Group Teleconference

21 May 2015

    [2]Agenda

       [2] https://lists.w3.org/Archives/Public/public-pfwg/2015May/0162.html

    See also: [3]IRC log

       [3] http://www.w3.org/2015/05/21-aria-irc

Attendees

    Present
           Michael, Fred, JamesN, Janina, Joanie, Joseph, MattG,
           Rich, Shane, Bryan_Garaventa, matt_king

    Regrets
    Chair
           Rich

    Scribe
           jamesn, clown

Contents

      * [4]Topics
          1. [5]ARIA extension process
          2. [6]ARIA extension process.
          3. [7]Review proposal by Ivan (dpub-ig) to allow DPUB
             module to be published with vocab- and work to move
             parts we need into Core
          4. [8]ARIA working group charter.
      * [9]Summary of Action Items
      __________________________________________________________

    <trackbot> Date: 21 May 2015

ARIA extension process

    <clown> scribenick: jamesn

    <scribe> scribe: jamesn

ARIA extension process.

    RS: Shane, any revised text?

    SM: No.
    ... I had a concept, but I wasn't going to change things until
    discussion.
    ... I sent them out in an email.

    ShaneM> Any ARIA extension specifications that have reached
    Recommendation status at the time the ARIA Core is revised and
    approved as a superseding Recommendation will be considered to
    be a part of ARIA Core and their non-optional components
    required of all ARIA conforming implementations.

    SM: The text I just pasted doesn't have consensus with the
    html-a11y taskforce, nor does Cynthia agree.
    ... I'm not sure Cynthia read this.
    ... But she came with her own position.

    RS: She didn't want to have IE compliant, and then another
    module comes online, and it is no longer compliant.
    ... She doesn't want to tie ARIA compliance to extensions.
    ... We need to find a way for them to support ARIA stuff; need
    to reword.

    JS: Without requiring the native browser to support these other
    vocabularies.

    JN: It seems reasonable to have a dedicated reader, and then if
    a browser extends itself...

    RS: We could reword this.
    ... <starts typing suggested new wording>

    <richardschwerdtfeger> meeting: W3C WAI-PF ARIA Caucus

    [10]https://www.w3.org/WAI/PF/wiki/ARIAExtensions

      [10] https://www.w3.org/WAI/PF/wiki/ARIAExtensions

    <clown> scribenick: clown

    RS: Here's a proposal for bullet 4

    <richardschwerdtfeger> Proposal replacement for bullet 4: If an
    extension and its corresponding accessibility API mapping
    specification becomes a W3C Recommendation then the extension
    provider should work with browser manufacturers to get
    adoption.

    SM: I don't see how my proposal doesn't address Cynthia's
    criticism
    ... If we have an extension, and it gets to REC, that means it
    has two different implementations.

    JS: Those might be a reader, and not necessarily a browser.
    ... If we have very specialized vocabs, browsers might not want
    to support that.

    SM: Why does a browser have to support? Nothing.

    JN: We don't know that until we get there.

    JD: The rendering engines are going to have to do something.

    SM: Can you give an example?

    JD: Are we talking about the roles?

    SM: Let's say chapter.

    JD: How does that get mapped? New role? Object attribute?

    SM: It's a role value; it's already being exposed.

    Joseph: Yes it does. It's not just a pass through.

    JD: Maybe it could just pass through, but we can't assume that.

    SM: Let's pretend there is a mapping.
    ... So, chapter maps to CHAPTER.

    <jamesn> I have no browser so have no skin in this but I can't
    support Shane's proposal

    JD: If they don't map chapter, then they are not compliant.

    <jamesn> I have to go as I have a conflict at the hour

    SM: For that version of ARIA. Isn't that the same problem as
    today?

    JD: I understand Cynthia's concern that if IE doesn't implement
    DPub, they might be deemed non-compliant.

    SM: I hear you, but if these are optional, that should be ok.

    JD: I'm not sure your text says that.
    ... <reads text>

    SM: <reads his text>

    JD: Let's say we do ARIA 1.2, and we put in a lot of new cool
    features.
    ... Meanwhile, DPub has made it to REC, are browsers compliant?

    SM: If they don't support the non-optional parts, then they are
    not compliant.

    JD: What means "non-optional"?

    SM: That is part of the process; deciding what is mandatory vs.
    optional.
    ... There has to be a way programmatically way to determine
    what is available, as an author.

    JD: Is there a way to do that with CSS, say?

    SM: Good question. Not with CSS as it happens.
    ... But CSS is built to gracefully degrade.
    ... But, if DPub chapter role is not supported, I have an
    immediate a11y failure.

    <Zakim> ShaneM, you wanted to ask why my proposal doesn't
    already address cynthias proposal?

    SM: If we allow things to not be implemented, then there must
    be a way to determine that.

    JD: Agreed.

    RS: So, how are we going to proceed here?
    ... We are going to run into non-compiance generally.
    ... We could do an ARIA 1.2 that includes DPub.

    <Zakim> clown, you wanted to note how we get to CR (by testing
    implementations).

    <Zakim> janina, you wanted to say that if it's just passing a
    string value in the already support role code, then we should
    be OK for mandatory

    <ShaneM> I note that the wiki says that extensions must include
    tests, etc.

    JS: Maybe we should see if HTML has enough use cases before
    proceeding.
    ... Point 2: optional vs required: can we just add a bunch of
    strings and the mechanisms will expose them.
    ... The problem is if they have to do extra coding to expose.

    RS: I have not seen anything on WebKit where the role value is
    passed through.
    ... Is there a problem separating these modules from the core
    in terms of compliance.

    MK: It's up to the group to say whether something is optional
    vs. non-optional.
    ... Does that mean an optional is "optional for DPub" or
    "optional for Core"?

    SM: 1. This thing is optional, but if you implement it, you
    must implement x, y, and z.
    ... 2. There are non-optional parts of this thing that must be
    implemented.

    MK: So any normative MUST inside DPub, and you implement it,
    then you must be implementing those mandatory parts.

    <ShaneM> Here is some text from the Role Attribute
    recommendation: If a Host Language contains the @role
    attribute, then an RDFa processor processing a document written
    in that Host Language according to the rules of that Host
    Language may generate additional triples for role attributes.
    If these additional triples are being generated, then they must
    be generated as follows:

    MK: So, optional is for the entire extension.

    SM: See the text I just put in IRC.

    RS: They are going to have normative requirements that, say, an
    epub reader must comply with.

    <richardschwerdtfeger> If an extension and its corresponding
    accessibility API mapping specification becomes a W3C
    Recommendation then the extension provider should work with
    browser manufacturers to get adoption.

    RS: How about that way of putting it?

    TS: If we are saying adoption means supporting the a11y
    mappings…

    MK: That doesn't seem to be the same thing as we said before.

    <richardschwerdtfeger> If an extension and its corresponding
    accessibility API mapping specification becomes a W3C
    Recommendation then the extension provider should work with
    browser manufacturers to get adoption of the accessibiity API
    mapping.

    TS: We just said that the whole extension spec is optional.

    <ShaneM> This text is fine. it is a small part of the overall
    text

    <ShaneM> +1

    RS: This is to handle cases where the browser doesn't support
    an extension.

    MK: That makes this the responsibility of the browser
    implementor.
    ... Any compliant user agent would have to support that
    extension when it comes into core.

    RS: And, it would have to support the mapping spec.

    CS: I don't see why people why people are worried about putting
    it into the core spec.

    <richardschwerdtfeger> If an extension and its corresponding
    accessibility API mapping specification becomes a W3C
    Recommendation then the extension provider should work with
    browser manufacturers to get adoption.

    CS: That won't necessarily cause browsers to implement it.

    RS: How about the above wording, Cynthia?

    SM: I don't think it replaces 4; it's just additional text.

    RS: It doesn't tie core compliance with the module.

    SM: It doesn't say that.

    CS: I don't think extensions have anything to do with core, and
    Shane thinks they do.

    SM: You missed the earlier discussion. I've caved on that.

    JS: Will trident copy the role string?

    CS: Yes, it does.

    JD: We aren't just adding strings. If there are states, etc.
    associated with the role, that needs to be considered.

    MK: It depends on whether the role carries any normative
    requirements for the user agent.
    ... Take alert role for example.
    ... I don't think the vendor has a problem with just copying a
    string.
    ... As long as all extensions are optional unless PF says this
    extension isn't optional.

    RS: I would say either you support it or you don't.

    <ShaneM> I note that this is exactly how modules were defined
    for XHTML 2

    MK: If all extenesions are optional unless PF says this one
    isn't, then you aren't ARIA compliant with respect to that one.

    RS: That depends on a discussion with the browser vendors.
    ... How should we reword this bullet?

    JD: I have slightly stronger language.
    ... <reads>

    <joanie> Compliant user agents are strongly encouraged to
    implement support for extension modules which have become W3C
    Recommendations. However, failure to support an extension does
    not mean user agents are not compliant with ARIA.

    CS: I kind of don't like that.
    ... It seems to imply it's bad to not implement.
    ... Object to "strongly encourage".

    JD: Let me try to reword this.

    JS, CS: <discussion about checking for implementations
    programmtically>

    SM: The thing that html killed is determining the version of
    HTML.

    CS: Version and module are different, however.

    SM: Right, but they don't have a way to detect modules either.

    <joanie> User agents are encouraged to implement support for
    extension modules which have become W3C Recommendations.
    However, ARIA compliance is separate from extension compliance.

    JS: Could we just do it for ARIA?

    CS: That is much better.

    JS: What is compliant vs. extension compliance.

    SM: I'll put it the wiki with the correct wording.

    <richardschwerdtfeger> Resolution: Group agrees to have Shane
    insert a modified version of Joanie’s proposal into the ARIA
    1.x extension process

Review proposal by Ivan (dpub-ig) to allow DPUB module to be
published with vocab- and work to move parts we need into Core

    RS: Here is what Ivan proposed.
    ... Relase a FPWD of DPub modular extension for ARIA with the
    "vocab-" in front of all the roles.

    <tzviya> Ivan's proposal from HTML-A11y call: my proposal would
    be the other way around. Lots of concern about global or not.
    We define all in namespace by default. Then we can decide
    during publication process if any should be general
    non-prefixed terms

    RS: PF then reviews and says which ones do need the prefix.

    TS: See my paste in the chat.

    RS: By agreement means: a call for consensus would be sent out.

    JS: What does it mean in terms of at-risk statements?

    RS: All the at-risk would disappear.

    MC: Timeline?

    JS: Let's say the 11th.

    MattG: That's good for me.

    JS: Once we have a resolutions, I will put out a CFC for a
    little longer than 48 hours, and everyone agrees, we will make
    the 11th.
    ... I need an URL to rawgit to point to as the FPWD.

    TS: We think we can get this done by the 4th.

    <discussion of time lines>

    RS: What is the prefix?

    <ShaneM> Kenneth, what is the frequency?

    RS: dpub- ? pub-?

    MattG: That's a good question. We will discuss and work it out.

    s/a good questiona good question/

    <richardschwerdtfeger> Proposal: The task force agrees to allow
    the the DPUB ARIA module to got to First Public Working Draft
    with all role values having a prefix with that has a hyphen per
    the ARIA Extension mechanism and to remove all at risk comments
    and to discuss afterward which roles should moved into ARIA 1.1
    core. This will result in a PF CFC.

    <richardschwerdtfeger> Proposal: The task force agrees to allow
    the the DPUB ARIA module to got to First Public Working Draft
    with all role values having a prefix, that has a hyphen per the
    ARIA Extension mechanism, and to remove all at risk comments
    and to discuss afterward which roles should moved into ARIA 1.1
    core. This will result in a PF CFC.

    <richardschwerdtfeger> Proposal: The task force agrees to allow
    the DPUB ARIA module to got to First Public Working Draft with
    all role values having a prefix, that has a hyphen per the ARIA
    Extension mechanism, and to remove all at risk comments and to
    discuss, after FPWD publication, which roles should moved into
    ARIA 1.1 core. This will result in a PF CFC.

    <ShaneM> +1

    +1

    <tzviya> +1

    <joanie> +1

    <mgarrish> +1

    <fesch> +1

    <richardschwerdtfeger> Resolution: The task force agrees to
    allow the DPUB ARIA module to got to First Public Working Draft
    with all role values having a prefix, that has a hyphen per the
    ARIA Extension mechanism, and to remove all at risk comments
    and to discuss, after FPWD publication, which roles should be
    moved into ARIA 1.1 core. This will result in a PF CFC.

ARIA working group charter.

    <richardschwerdtfeger>
    [11]http://www.w3.org/2015/04/draft-aria-charter

      [11] http://www.w3.org/2015/04/draft-aria-charter

    MC: I have been making mods. Let me update.

    RS: Includes ARIA 1.1
    ... CR date in Oct 2015
    ... DPub ARIA module, FPWD by June 2015
    ... Graphics module in Oct 2015
    ... Core mappings…
    ... Correct the label for the accname.
    ... SVG mappings, DPub mappings, User Context (needs the new
    name).
    ... ARIA 2.0 by Jun 2017.
    ... Cognitive module
    ... WAPA by spring 2016.
    ... This is the work we are talking about.

    JS: Cognitive and User context — why are these different.

    RS: User context is like IndieUI, an API for content delivery.

    MC: Cognitive is like a new vocabulary.

    JS: That should lead to cross pollination.

    MC: Might need a new name.

    CS: : On the API, is that a sone of WAPA and IndieUI, or
    analyzing the various platform APIs?

    RS: I think it's a joint effort with WebApps.

    CS: There are two different things.
    ... One is document.
    ... The other is to influence platform APIs.

    RS: The user context is an API in the browser.

    CS: So, this is along the lines of WAPA and IndieUI. Gotcha.

    MC, CS: <worries about name collisions>

    MC: I did not anticpate that this group would take on IndieUI
    events.

    RS: Well, it will adopt some of the ideas that came out of that
    group.
    ... But with the cooperation of WebApps.
    ... We also have to adopt things like web components.

    CS: How about a "Roadmap for web a11y API?"

    RS: Does that limit us, Michael?

    JS: We could change and ask for an amendment to the charter.

    MC: If we say "roadmap" but not put it in rec track, we would
    have to ask for an amendment.
    ... But, if we leave it on rec track, it's okay.

    CS: A previous term was "dynamic ARIA"
    ... : Or WAPA?

    RS: "WAI-ARIA interaction module"?

    CS: Can we change the name later?

    MC: Yes, if we are clear that "this" is "that" later on.

    RS: We also have a list of liasons with other groups.

    MC: Need to add APA.

    JS: Yes.

    RS: : I thinks "GPII" is actually "Raising the Floor".

    CS: IAAP?

    Joseph: IMS?

    RS: Yes, we might want IMS.

    <richardschwerdtfeger> [12]http://www.imsglobal.org

      [12] http://www.imsglobal.org/

    JS: ISO subcommittee <number>?

    RS: If you can think of it, give it to Michael, Janina.
    ... Michael, when you chair, can you triage the action items,
    get the assigned, and get people working on them.

    MC: Sure.

    <scribe> scribe: clown

    s/ShaneM>Any/SM: Any/

    s/ShaneM\>Any/SM: Any/

    s/ShaneM\\>Any/SM: Any/

Summary of Action Items

    [End of minutes]
      __________________________________________________________


     Minutes formatted by David Booth's [13]scribe.perl version
     1.140 ([14]CVS log)
     $Date: 2015/05/21 18:10:28 $
      __________________________________________________________

      [13] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
      [14] http://dev.w3.org/cvsweb/2002/scribe/
      [18] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm

-- 
;;;;joseph.

'Array(16).join("wat" - 1) + " Batman!"'
            - G. Bernhardt -

Received on Thursday, 21 May 2015 18:12:47 UTC