See also: IRC log
<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
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
<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
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
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]