See also: IRC log
<trackbot> Date: 13 August 2014
<janina> Meeting: PFWG telecon
<janina> agenda: this
<MichaelC> scribe: Tim
RESOLUTION: Minutes approved for public list
MC: meeting page with logistics,
no agenda yet, coordination with other WGs, please resgister
ASAP
... Wed of that week 20th Anniversary Symposium - please
register for that
Indie UI and WCAG will be meeting at TPAC also..
<MichaelC> close action-1480
<trackbot> Closed action-1480.
MC: no new LCs on TR page..
<MichaelC> Referrer Policy
FPWD - Referer Policy
REsolution: no need to review
CSS Ruby Layout
RESOLUTION: no need to review this version
MAUR scheduled for tomorrow publication
CR Longdesc published yesterday - formal objection expected - will be handled as appropriate
Cynthia review of Security Policy - has a few questions
MC: suggest send questions as personal comments
Cynthia - good things about it - a concern about ordering
RESOLUTION: send PF comment about automatic grid placement algorithm to CSS WG (per Cynthia's suggestion)
CYnthia - no issues with accessibility
<MichaelC> close action-931
<trackbot> Closed action-931.
RESOLUTION: no further action
<MichaelC> close action-932
<trackbot> Closed action-932.
RS: second pass on this - need to fill some gaps
what controls need to be in HTML 5.x - group has made a lot of progress
lots of problems with selectors using shadowDOM
may need to push to ARIA2
<MichaelC> filling gaps in native semantics
<MichaelC> doing stuff that can´t be done
<MichaelC> (can´t wait until ARIA 2)
clearing up confusion for author
<janina> /me Maybe we need a new scribe?
<MichaelC> jg: shadow dom issues?
<MichaelC> rs: lots of complexity
<MichaelC> how it works may evolve
<MichaelC> hidden from rest of web page
<MichaelC> only way to reference is via selector
<MichaelC> is exposed to AAPI
<MichaelC> don´t know how this impacts a11y test tools
<MichaelC> so lots to explore around it
<MichaelC> jg: so it´s a long-term solution for HTML 5 components
<MichaelC> canvas, applet, etc.
<MichaelC> js: if it proves robust, will rely on it
<MichaelC> but it might not survive as a mechanism
<MichaelC> so let´s not rely on it yet
<MichaelC> scribe: jongund
RS: Do we have an editors call?
MC: No
RS: I was going to ask an opinion ...
LS: I am in the que
... I am trying to fix... here is an inaccessible canvas, are
people actually recommended this
RS: We have almost done it, one
thing we are missing is hit testing
... I am not sure where the canvas work
JS: There is an HTML5 working
group, they are working on Version 2 of the spec
... They are meeting every other week
RS: I was out last week
... My understanding is the ARIA 1.1 hit testing is being
implemented, can't drive a magnifier at the moment
LS: It sounds like most things
work, it sounds like you can get Level A
... We need to go look at current Canvas implementations to see
if the shadow DOM works...
JS: This was your question
... The place to work on this is the canvas task force
... There is an active group
LS: Send me the e-mail list
RS: public-canvas-api
JS: We need to move on
MC: I think we have pretty much
dealt with this
... ... reading the proposal ...
... Can we adopt?
JS: I think we have a conensus in the group
RESOLUTION: Accept proposal
MC: We need to clean up the introductions to all of our specs
<MichaelC> Introduction Guidelines
MC: I have created a wiki page
with suggestions, mostly from me
... An introduction should have technical literacy, but may not
be familiar with the technology
... It should scaffold in more technical details, don't assume
people know ...
... Should explain the problem it is solving and how it solves
the problem
... It should not use spec language, it should be entirely
non-normative, examples using diagrams
... Who should implement the spec and what would happen if it
is not implemented
... Any questions or thoughts?
JS: I really like the list, I like the tone and langauge
RS: What seems to be missing the objectives and why
JS: It is in there, but it is buried
RS: Do you want to type in the drafts I have developed?
JS: We are complaining to other groups about the problems with their specs, we want to set an example to other groups
MC: Its in a wiki so it can be edited, is there any thing missing?
RS: How does this relate to other documents
MC: A good one
... Let me take some notes
... Reorder.... I will talk to JS.. how this relates to
others
... Other thoughts?
... We hope to apply them to current documents being
developed
... This will be a good resource for us and other groups
JS: Shane is not on the
call
... It was tasked to me, but Shane picked it up and there was a
lot of list discussion and concerns, we need to keep this
open
MC: We need to file a working group comment
JS: This will be a big decision for us
MC: CSS spec that is in first
public working draft, not recently been updated
... It is specifying some features from member companies
... It can put constraints on how a web page is viewed on
different size and reolution
... The accessibility concern, there is a zoom property, which
can disable zooming all together, very deliberate way
preventing zoon
... User agents would be constrained, causing a basic
accessibility problem
... It is implemented, so there is a problem to tell people to
remove this functionality
... Should we file a comment, and ho hard should we push?
JF: In some ways it is addressed
in WCAG, the ability to enlarge....
... We should make a comment related to the WCAG comment,
advise them not to do this
MC: We could write a failure technique for WCAG
JS: Real goal is to get it out of the W3C spec
JF: That will be hard to do, specs are suppose to reflect implementation
JS: Aren't developers asking for
this problem if the spec is not complete, we need a bar..
... We need to discuss this further
MC: We definitely need to discuss this more
LS: I agree with JS we need to discuss this more, we don't approve a spec that is definitely not accessible
MC: We have approved specs with
accessibility issue
... this particular spec is about particular values