W3C

- DRAFT -

Protocols and Formats Working Group Teleconference
07 May 2015

Agenda

See also: IRC log

Attendees

Present
Fred_Esch, Stefan_Schnabel, Joanmarie_Diggs, Rich_Schwerdtfeger, janina, Markus, ShaneM, Michael_Cooper, Matt_King, James_Nurthen, Cynthia_Shelly
Regrets
Chair
Rich
Scribe
MichaelC

Contents


<trackbot> Date: 07 May 2015

<richardschwerdtfeger> meeting: W3C WAI_PF ARIA Caucus

<richardschwerdtfeger> http://www.justice.gov/sites/default/files/opa/press-releases/attachments/2015/04/02/edx_settlement_agreement.pdf

<richardschwerdtfeger> https://lists.w3.org/Archives/Public/public-pfwg/2015May/0047.html

<richardschwerdtfeger> : http://www.justice.gov/sites/default/files/opa/press-releases/attachments/2015/04/02/edx_settlement_agreement.pdf

<scribe> scribe: MichaelC

Zakim decomissioning

js: Zakim bridge will be turned off due to cost

switching to WebEx, which has no marginal cost to W3C because of MIT agreement

will still use the Zakim bot in IRC, but it won´t identify callers

have to transition within a few weeks

Web interface to WebEx not terribly accessible

but smartphone clients seem to be

need to test out soon

mc: you can dial out, request it call you, or use its VOIP feature

best to install the client before the meeting starts

mk: what about passcodes?

mc: different passcode for each meeting

but a given meeting can have the same passcode week to week

<richardschwerdtfeger> https://www.w3.org/WAI/PF/Group/track/issues/709

rs: issue with passcode collision with different dial-in numbers?

mc: afaik it´s a global system, no passcode collision

Issue 709 Define an Extension Mechanism for ARIA roles

<richardschwerdtfeger> https://lists.w3.org/Archives/Public/public-pfwg/2015Apr/0160.html

rs: ^ starting proposal

mk, rs: <scribe didn´t catch enough context>

rs: need AAPI mappings for new roles

some things may not map

mk: in which case how does it pass CR?

mg: implementations needn´t be limited to browsers

an epub reader could be a valid test target for DPub roles

though guess we want to check with W3C process

rs: think we´d want in browsers or authoring tools

for ARIA 1.0 we looked for two implementions of each role in the mapping table

mk: note we didn´t look at AT implementation

mg: publishers are interested in other things than AT mapping

doing element repurposing

affects authoring more than rendering

rs: benefits a11y for AU tools to support that

mg: but for CR, not necessarily expecting to measure AAPI mappings, if there are other things of interest to measure

rs: think there should be AAPI mappings for DPub extension

mc: W3C process doesn´t force certain interpretation of CR

<Zakim> joanie, you wanted to talk about what all "mapping" might mean wrt exposure

we´ll have to decide in our extension planning whether AAPI mappings is a hard requirement

jd: In cases where things are "not mapped" (e.g. to a specific role), they can still be exposed (e.g. via an object attribute). This exposure to accessibility APIs would make it possible to implement, and verify implementation of, items in extensions like DPUB.

<Zakim> ShaneM, you wanted to mention that I don't think authoring tools are relevant to CR for ARIA specs (today)

sm: don't think authoring tools are relevant to CR for ARIA specs (today)

we have avoided conformance requirements targeting AU tools

what sort of things are not mapped?

rs: rowgroup wasn´t mapped in 1.0 (for one platform)

sm: what does that mean?

rs: the ARIA role was discarded on that platform

sm: my proposal is any new roles have to map into taxonomy

so what you´re saying isn´t about that, it´s about AAPI mapping

rs: right

important to tell AT what to do

mk: if an extension didn´t have a mapping, what value does it bring?

rs: platforms are different

<Stefan> +q

mk: but what about if no mapping on any platform?

rs: example: role=¨part¨

doesn´t help AT, but helps authors, or someone doing landmark navigation

helps to have the semantics present

<Zakim> joanie, you wanted to reiterate what she was saying, in response to Matt's current question.

jd: say ¨part¨ was really important for AT

there could be an object attribute, that an authoring tool could get at even though not a direct AAPI feature

rs: one API turns on ¨isLandmark¨ but doesn´t expose specific role

mk: something with 0 exposure has no value

still need *something* defined

jd: yup

the DAAM would provide that

<MC calls it the DPub-AAM to avoid that acronym>

js: we can negotiate CR exit criteria

and global requirements are fairly loose, there´s room for negotiation

some of it depends on the specific wordign we choose for the spec

just need to demonstrate something reliably happening

there may be cascading situations where need to test more than 2 to work out the permutations

ss: @@ extensions properties

rs: the properties mechanism might be more owrk

ss: what about expandable region descending from region?

general case of pattern taken from base role

rs: that´s ARIA 2.0

we´re just dealing with name conflicts now

<Zakim> Michael_Cooper, you wanted to talk about speculative mapping

mc: we might want roles that map to features that don´t yet exist

rs: don´t want to throw stuff over the wall

mc: in that case we would say ¨expose an object attribute¨

but might want to say ¨we´d love a more direct feature¨

mg: we can provide mappings in the DPub-AAM for DPub roles

some of the mappings might be the same as ancestor roles in the taxonomy

<Zakim> ShaneM, you wanted to ask why new roles cannot add other states or properties that are already defined?

sm: if we collaborate we should be able to avoid collisions

we don´t yet have a way to add new states and properties in extensions

but can extensions use existing states and properties?

rs: yes

jn: what about new values for states and properties?

rs: that would change existing roles

jn: yet that´s needed for extensions

rs: lots of work to do on that level of extensibility

mc: I´m hearing we have 2 extensibility levels now

a full fledged one for ARIA 2

and some immediate needs that are more constrained

let´s sort what goes into which bucket

and then focus on supporting the immediate case

mk: did you mean to be so specific in extension restrictions?

sm: HTML 5 constrains us, can´t use full extensibility features of the Role Attribute

so we have to sort out what to do in a single namespace

rs: which is why we have aria-* for properties

mk: problem with multiple hyphens in a property name?

rs: expect to use vocab-aria-property pattern

a lot more to sort before we get there

<Zakim> mattking, you wanted to ask about - vs : as the myvocab separator

<ShaneM> I don't mind using aria-foo-stateName for extensions...

mc: why ¨MAY¨ descend from existing taxonomy

sm: so not constrained by existing taxonomy, if it lacks features

mc: can extend from roletype at least, suggest that be must extend taxonomy

js: we need a thorough consensus test on this

mc: yes, plus we also need really solid documentation

we spent an hour discussing questions on the proposal, need to give more specific answers to DPub to allow them to restart work

mg: don´t have that clarity just yet

want to avoid getting deadlocked again

<Zakim> ShaneM, you wanted to say I dont think this proposal addresses the core issue

mk: would this go in the ARIA spec?

sm: no

mg: why?

sm: the core issue that came up after proposal went out

is that people want to propose roles without semantic value

that´s not an extension issue, that´s a ¨what is role for¨ issue

we need a way for people to be able to add roles and not be called idiots

js: so we may need to have that ¨what is role for¨ discussion as well

need to have something solid before we tell DPub to go ahead

rs: some of the discussion on DPub echoed our past experience trying to put ARIA in HTML

we´re not the DPub experts and don´t think we should bottleneck the work of those who are

<joanie> +1 to our not being DPub experts

<ShaneM> Hyphenation is NOT the issue here

yes, the issue of hyphenated role values was an issue

but other discussion of valid roles is beyond our scope

DPub should be welcome to define roles

<Zakim> joanie, you wanted to ask if the way forward is the new AAM

we just need to sort out potential collisions if they want un hyphenated role names

jd: is the next step to work on the DAAM?

think would find some really interesting stuff there

maybe that would address philosophical problems

mc: concern that you can´t have mappings without something to map from

wanted to put up roles, then map them

could work on the roles and mappings together, but would be a while to publishing

they were trying to go step by step

jd: but it didn´t work out

<Zakim> ShaneM, you wanted to ask how the mapping is different than saying what the parent role and additional properties are?

should find paths forward that don´t depend on FPWD

sm: what does the mapping offer?

jd: let´s take example of a footnote

would love to add that to ATK

could work on that while people debate the merits of footnotes

sm: we do want to avoid implementation before we have basic agreement on the structure

or we get boxed in with future directions

that happened in ARIA 1.0

rs: there is always something sub-optimal

mk: tend to take FPWD as signal to start exploring implementation

js: need to think through the consequences carefully

there are legitmate clashes from different vocabularies

<joanie> For the record, I'm not a blocking person.

but we can´t rewrite centuries of usage of a particular term

need to figure out how to accomodate the legit clashes

cs: prototyping can be a good way to play with implementation without being over-committed

rs: want to prevent negative interaction with DPub TF

we´re not going to redefine the publishing industry

straw proposal - if a group puts role values in their own hyphenspace, we should not push back on the role

(though have to talk about it if incorporating into ARIA core roles)

jn: no concerns if its in their hyphenspace, but original proposal was to put in the null hyphenspace

<Zakim> ShaneM, you wanted to say I agree with Rich but dont think it would solve the problem

sm: the core issue that came up was ¨this does not add to a11y¨

we are not in a position to say that

jn: it´s not a correct argument that was brought up

knowing what something is makes it easier to get to it

sighted people have been doing this since Gutenberg, screen reader users only since DAISY

rs: proposed resolution: If a group wants to put roles in their own hyphenspace, they have last say in what goes there

mg: there was a discussion about scope of the role attribute

is it only a11y, or is it more generic?

have heard one thing, but also had W3C staff blatantly ignoring it

<ShaneM> +1 to needing a positive statement from the PFWG about the scope of role values.

js: think it´s a political argument, that it´s beyond mandate of PFWG to propose non-a11y roles

whereas our POV has been to invite people to take curbcut advantage of things like this

mg: but get a different answer from HTML WG

rs: as long as it doesn´t break AAPI mappings, people should be able to use from beginning

<Zakim> Michael_Cooper, you wanted to compare HTML role from Role Attribute

sm: yes, long post on HTML list

mc: PF published Role Attribute which clearly invites non a11y roles

so we have precedent

but have to negotiate with HTML inclusion of values in the HTML role attribute

which only accepts ¨ARIA roles¨

could put us in a situation of needing to define ¨a11y ARIA roles¨ and ¨other recognized roles¨ - which might be helfpul or anathema

<richardschwerdtfeger> ACTION: Shane work with Rich on updated process for creating new role value taxonomy extensions [recorded in http://www.w3.org/2015/05/07-aria-minutes.html#action01]

<trackbot> Created ACTION-1633 - Work with rich on updated process for creating new role value taxonomy extensions [on Shane McCarron - due 2015-05-14].

rs: SM, let´s work it up again

mk: @@

sm: HTML 5 has an extension mechanism, we need an extension mechanism

mc: thought the HTML on is very informal, doens´t say how conflicts managed

Review Open Action Items and Issues

rs: there are lots of actions that are not gettign done

need to assign some of them

action-1073?

<trackbot> action-1073 -- Matthew King to Update aria-selected to reflect that it communicates selectability and clarify responsibility for ensuring aria-selected=false is on selectable elements -- due 2015-03-26 -- OPEN

<trackbot> https://www.w3.org/WAI/PF/Group/track/actions/1073

<richardschwerdtfeger> https://www.w3.org/WAI/PF/Group/track/actions/1073

mk: ???

<joanie> https://rawgit.com/w3c/aria/master/aria/aria.html#aria-current

rs: looking at actions for aria-current

mk, jd: think they´re done

<richardschwerdtfeger> In some use cases for widgets that support aria-selected, current and selected can have different meanings and can both be used within the same set of elements. For example, aria-current="page" can be used in a navigation tree to indicate which page is currently displayed, while aria-selected="true" indicates which page will be displayed if the user activates the treeitem. Furthermore, the same tree may support operating on one or more selected pages

<richardschwerdtfeger> (treeitems) by way of a context menu containing options such as "delete" and "move."

close action-1573

<trackbot> Closed action-1573.

action-1363?

<trackbot> action-1363 -- James Craig to Patch issue-603: aria-startsmedia -- due 2015-03-12 -- OPEN

<trackbot> https://www.w3.org/WAI/PF/Group/track/actions/1363

rs: JD, can you take this?

jd: I don´t agree with it, think someone who agrees with it should work on it

mk: could move to ARIA 2

jn: or propose ¨wontfix¨

rs: will move issue-603 to ARIA 2.0
... out of time; enough to bring up for next week?

jd: do we need to start thinking ARIA 1.2?

rs: bigger discussion
... for heartbeat, want @@ in the spec

mc: I have to start publication prep Monday, and need a WG consensus by Wednesday

and all that is pushing the timeline

js: we don´t know if we can publish for a while, if we don´t publish by 14 May, because charter discussion is not closed

jd: MK and I will try hard to do it for Monday

js: everyone please vote on the Authoring Practices FPWD

Summary of Action Items

[NEW] ACTION: Shane work with Rich on updated process for creating new role value taxonomy extensions [recorded in http://www.w3.org/2015/05/07-aria-minutes.html#action01]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015/05/07 18:07:15 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.140  of Date: 2014-11-06 18:16:30  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/@@/In cases where things are "not mapped" (e.g. to a specific role), they can still be exposed (e.g. via an object attribute). This exposure to accessibility APIs would make it possible to implement, and verify implementation of, items in extensions like DPUB./
Succeeded: s/Hypenation/Hyphenation/
Found Scribe: MichaelC
Inferring ScribeNick: MichaelC
Default Present: Fred_Esch, Stefan_Schnabel, Joanmarie_Diggs, Rich_Schwerdtfeger, janina, Markus, ShaneM, Michael_Cooper, Matt_King, James_Nurthen, Cynthia_Shelly
Present: Fred_Esch Stefan_Schnabel Joanmarie_Diggs Rich_Schwerdtfeger janina Markus ShaneM Michael_Cooper Matt_King James_Nurthen Cynthia_Shelly
Agenda: https://lists.w3.org/Archives/Public/public-pfwg/2015May/0047.html
Found Date: 07 May 2015
Guessing minutes URL: http://www.w3.org/2015/05/07-aria-minutes.html
People with action items: shane

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


[End of scribe.perl diagnostic output]