Protocols and Formats Working Group Teleconference -- 21 May 2015

<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

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.

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.

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.

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

<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> 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> 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/

- DRAFT -

Protocols and Formats Working Group Teleconference

21 May 2015

Attendees

Contents

ARIA extension process

ARIA 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

ARIA working group charter.

Summary of Action Items

Scribe.perl diagnostic output