- From: Joseph Scheuhammer <clown@alum.mit.edu>
- Date: Thu, 21 May 2015 14:12:15 -0400
- To: public-pfwg@w3.org
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