See also: IRC log
<trackbot> Date: 08 October 2014
<janina> http://www.w3.org/WAI/PF/meetings/tp2014
<janina> trackbot, start meeting
<trackbot> Meeting: Protocols and Formats Working Group Teleconference
<trackbot> Date: 08 October 2014
<janina> agenda: this
<janina> http://www.w3.org/WAI/PF/svg-a11y-tf/work-statement
<JF> scribe: JF
JS: any items?
RESOLUTION: Publish previous minutes as submitted
JS & RS discussion meeting with SVG WG at TPAC
<janina> http://www.w3.org/WAI/PF/svg-a11y-tf/work-statement
JS: Leaving Friday morning for
CSS concerns, hoping CSS regulars will be able to join us then
- no official overlap schedule-wise
... thursday meeting with Web & TV IG - have asked to have
a firmer agenda (topics to discuss)
already a strong connection with this group in the past
other meetings scheduled for the first morning
after lunch is meeting with D-Pub folks
Have also invited Markku to join us to discuss testing (etc.)
JS: anything missing or needing more effort?
nothing important being missed
returning to web events topic
James N and James C both feel we should be approaching HTML WG regarding this (DOM related)
Q: do we want to request feature support for
Event Enumeration?
JS: propose we lay out the problem, ask for suggestions/solutions, offer some ideas, but leave with them to solve it
so, why do we want event enumeration? Primarilyfor testing, including across multiple environments
SC: want to review the mintues, but this sound right
JS: agreed, this surfaced earlier, but needs more discussion
CS: seems like we need to have the conversation about the Pros and Cons
RS: as discussed monday, this has been rejected previously due to security concerns
JS: SC has raised this before
CS: things that are hard but
do-able are prime security targets
... what about approaching the HTML WG with the problem
statement and ask for brain-storming
JS: this would off-set any push-back, so we bring them the problem and ask the for some input
{consensus on that approach}
JS: we will need somebody on our behalf to lay out the case for why we need this
CS: who has been suggesting this initially?
JS: not sure. Shane has been carrying the water to date
Believe the drive comes from Jon G - it relates to testing etc.
SC: Happy to write something up in preparation
JN: question the utility of event
enumeration, doesn't sound like it is going to happen, but if
they can come up with another way to solve this then
great
... we are asking for something for a testing tool, this won't
have an impact on end-user experience
that won't trump security
RS: if/when we go to device independance, then there may be some value
JN: there are already
alternatives for testing. All of this is already accessible via
the browser, but not from/for JS and the DOM
... there are levels of trust
CS: whether it is neccesary to catch this from the web-browsers is an open question
JN: adding a new hole will not be well received by security folks
RS: don't think that this is adding a hole. you can enumerate them without executing them
CS: maybe some kind of web component or browser extenstion
RS: with a lot of stuff going into CSS today... a lot of web-accessibility is being taken from the DOM. WE may want to think about how WCAG addresses compliance - look at interop layer
CS: agree there
RS: there is an issue - you can
have an image, and add the alt text via a CSS _______
... maybe we need to look at this at a different layer
JS: needs more discussion. returning to TPAC agenda, we have a number of issues around CSS already
James CRaig has suggested to invite Tab Atkins and Fantasi
CS: suggest also inviting Rossen A. as well
RS: is WCAG going to be there?
(they are meeting Sunday/Monday)
RS: suggest they be involved as well
CS: one more suggestion about the events enumerations - involve components
JS: tend to agree, but Chaals keeps suggesting not them
CS: we could invite Ben Peters
JS: any other TPAC items?
action 1517
<MichaelC> close action-1516
<trackbot> Closed action-1516.
<MichaelC> close action-1511
<trackbot> Closed action-1511.
<MichaelC> close action-1512
<trackbot> Closed action-1512.
<MichaelC> close action-1508
<trackbot> Closed action-1508.
<MichaelC> close action-1500
<trackbot> Closed action-1500.
<MichaelC> close action-1502
<trackbot> Closed action-1502.
Both JN and CS have comments about fixed zoom
<MichaelC> XSL Transformations (XSLT) Version 3.0
MC: only one LC
CS: is anyone still using that?
MC: it isn't usually related to front-end, but can have an a11y impact
<MichaelC> Media Capture Depth Stream Extensions
JS: we could ask them for a more human-readable abstract: what does it do and what are the use-cases?
CS: that's a reasonable ask
JF: suggest we watch this one - may be interested
CS: have they considered how to make this work for people who lack depth-perception
MC: that may be a non-question at
this time, we don't know
... will draft a response
<MichaelC> Selection API
MC: this appears to be a follow-on from an earlier attempt - needs editorial work
This originates from a Community Group
MC: not sure about next steps
JS: this is related to WebApps - they have previously asked us to flag things that need work in the past - they are open to hear from us
(concern about the fact that it is also written in first-person)
<MichaelC> ACTION: joanie to draft comment on Selection API http://www.w3.org/TR/2014/WD-selection-api-20141007/ [recorded in http://www.w3.org/2014/10/08-pf-minutes.html#action01]
<trackbot> Created ACTION-1518 - Draft comment on selection api http://www.w3.org/tr/2014/wd-selection-api-20141007/ [on Joanmarie Diggs - due 2014-10-15].
<MichaelC> scribe: MichaelC
Joanie to prepare comment, Michael to request clearer frontmatter