See also: IRC log
<trackbot> Date: 19 February 2015
<JF> scribe: JF
CM: welcomes Robin
... looking to formulate plans for the next months, so we need
a plan. Robin has some thoughts to offer
<darobin> http://darobin.github.io/after5/html-plan.html
RB: happy to share, and can
return to future calls to discuss further as required
... 13 - 15 page document linked. Suggest a deeper read
off-line
high-level plan is to work to make html more creative, exciting, etc.
much of the energy over the past months was to ship html5, now we can expand
one objective is to reduce overhead in the production of the spec - required a lot of resources
RB: idea now is to shift the efforts of the work on newer more interesting content
one of the big changes is to have more smaller groups to work on the effort.
idea is anything that is feature focused would be done in a smaller group
to avoid chaos, there will be a master plan/map, but the idea is to allow smaller groups to work
another key point will be how to deal with bugs
propose to deliver bugs to WHAT WG, and have an escalation path through the html wg
for groups who are unhappy with this, then will address more directly
one thing to avoid is to avoid bug dupes
As far as new features - goal is to have a smaller spec, not a larger one
may look to split-off the spec - for example if someone is working a a feature, it may be extracted and worked on as an extension spec
<chaals> scribe: chaals
JF: You talked about possibility of bugs traveling in parallel paths. How do you manage that?
RB: Idea is not to have them in parallel. If it is something WHATWG will handle, send it there, if you don't want to do that, don't like the resolution or it is on something like longdesc that isn't in WHATWG, then we'll move it to HTML (or file it there to start)
… instead of having two groups trying to figure out what each other were doing, and wasting a lot of time on redundant work.
… and confusing people…
<scribe> scribe: JF
SF: to provide a practicle example, points to performance requirements for ARIA, and yet they have created a new version which will be used [inaudible], at the same time the requiremens which are all in the HTML API mapping section
that current section in the ARIA section will include the few bits around roles, etc.
but the API mapping requirements will be ported off
RB: progress on that now
CM: there has been some time shopping this around - the HTML group has been quite open to feedback
<SteveF> html api mappings 1.0 http://rawgit.com/w3c/aria/master/html-aam/html-aam.html
this seems to be a good balance
one question: for groups such as this, what do we anticipate what we need to track and monitor?
<SteveF> conformance requirements for ARIA in HTML https://specs.webplatform.org/html-aria/webspecs/master/
RB: yes, we have already seen that kind of feedback
the goal is to produce a map of what is being worked on where
which would be part of the beginning of the spec
want to also ask groups to outline how they want to work, and how to provide feedback
RB: also talking about how to properly document extension specs
including how to do some self-monitoring
which would aid prior to a horizontal review
this is the plan, and there will be hickups, but this is the general idea
JB: appreciate this discussion and that W3C Team addressing some earlier concerns
also welcome the division between Task Forces and Community Groups
important to have some coordinated oversight to address efforts across multiple channels
there is a scalability concern with a proliferation of CGs
steps to work and ensure that CGs can ensure a11y
final point: concern around documents coming from CGs labeled "final", with the assumption that specs are fully baked (but not had a11y review, for example)
RB: we are aware of this, and it is being tracked. People should not move towards "final specification" rather than "final report" prior to multi-group review
JB: yes, there are may options, but appreciate serious review
JS: want to focus on bug process. Appreciate attempt to make it more responsive, but note that re: a11y - starting at WHAT WG opens possibility of concern
WHAT WG does not have the same depth of a11y participation
would be far more comfortable if other groups also started bugs at W3C - concern over history of annimosity with WHAT WG
+1 to Janina
RB: agree with that sentiment. do not want to create a situation where people avoid filing bugs for fear of fallout
agree that a11y area may bve one of those areas
in terms of general policy - it would be not that we are making an exception for a11y, but to extend that to any group who may have similar concerns
there are other groups with similar concerns based on history
RB: hoping to see further feedback (on list)]
<Zakim> chaals, you wanted to respond on bug process
CM: part of the issue about building trust - you need to step forward
there are many people who file bugs in many places
CM: we run the risk of over-processizing this
file the bug where it best makes sense
<LJWatson> +1 to Chaals.
<joanie> +1 to chaals
JS: don't want to run the world, but we want to avoid repeating previous actions
<Zakim> Judy, you wanted to mention some discussion w/ Jeff
JB: have a few thoughts on the bug-tracking issue
html wg is refreshing their work, so it may be interesting to see how this evolves
have been discussing this with Jeff as well as to how this would work/look
html wg is responsible to ensure that bug tracking is working
it may be difficult to track a by-pass route
one possibility would be to establish a success criteria on how bugs are being processed
JB: but hear significant concerns around bug tracking
<Zakim> JF, you wanted to ask about tracking bugs in a space we are less effective
<chaals> scribe: chaals
JF: To echo some of what Judy said, I am concerned there is an appearance of two places to file bugs.
… true we cannot control the world, but unless there is a process that says any accessibility bug filed at WHAT-WG comes to the attention of this task force, we will need to monitor those bugs or things will slip through.
… we shouldn't be relying on people trying to figure out where to file bugs.
<inserted> scribe: JF
<Zakim> chaals, you wanted to point out filing direct with HTML is not an escalation or bypass, it is one of the two possible initial options for filing a bug.
CM: 2 comments: 1 there are 2 places to file bugs today - there are 2 groups working on HTML, Doing a lot of duplicate work is expensive. There is a general concern over bug tracking
<SteveF> the current/old way was to triage html wg bugs, be same for new bugs on whatwg no?
CM: any bug fix proposed by WHAT WG will be passing through the HTML WG
LQ: do not expect saying that there are 2 places to file bugs
there should be a single site to file bugs, and a single site to track bugs
+1 to liam
<SteveF> w3c owns w3c bugzilla, that is where the bugs are filed
LW: believe bug tracking *is* in one place
W3C bugzilla
<janina> +1 to Liam, that proposal would then put the onus on who the bug is assigned to
<liam> [then it's not a problem :-) ]
CM: encourage people to read the plan, and note that it changes. May want to invite Robiun back
the other part of this is the work plan
we are looking to issue a CfC to decide whqt this group will work on - roughly a charter of what we will be doing here
the wish-list wiki is where we are documenting this
there is a specific issue aropund the work on ARIA - this group is not being actively worked on here.
we can either ask to move that here, or we can leave it to operate outside of this TF
JS: work is happening on the API mapping by Steve and Jason - it is bigger than just ARIA
CM: asking steve if work is happening, andif so, where?
SF: there is activity - Jason and
I have done some work. When there is something to post, I post
it to this WG (as well as PF)
... do not need to be in the TF to work on the doc. If you have
contributions you can file a bug or send an email
CM: part of the W3C process is to ensure that a11y work is being tracked. If PF is tracking efforts already, then does this group need to track the same work?
SF: suggest that the expertese is in the HTML WG and the PF WG
JS: would agree. Concern that PF being asked to track issues that are not a11y related - happier to see that continue being worked on in this TF
PF decided to move all issues related to HTML to this TF
SF: people can contribute and provide feedback - if we can facilitate that we are ahead
CM: comment and suggestion: as a browser vendor and content creator - minimizing the number of things and places to track is a good thing
propose we place the documents up as proposed work items, and see what feedback we get
<Judy> [Judy does not see harm in maintaining a lightweight tracking list, but doesn't want to debate it further]
CM: this group is formally tasked with tracking all of the a11y issues for HTML
JS: there has been some activity this week (drawFocus) - advances at Google. Dominic was asking some questions around specific code, under code-review at G now.
No news on the single Firefox bug; Joanie is also looking at support in WebKit
JS: for one week now we've been making excellent progress
CM: good news!
... is that Chrome code or Chromium code? if Chromium then it
is also picked up by Yandex and Opera
JS: Good question - will need to verify
CM: what is the status of hitRegion?
JS: will need substantially more work. If we want to mve forward suggest to not wait on hitRegion
suggestion to move that to "level 2"
Chairs agreed getting that would justify a level 2
JB: there is still some discussion around this - other suggestion would be to have a 1.1
sugest that the plan be flexible. It is aproblem with going out without hit Region, but... starting to see some complaints on inaccessible Canvas
JB: there are some things complicating the decision process. Have re-escalated this internally. Process suggests that news be announced in 2-3 weeks
there are some concerns that this hasn't happened
it is going to the AC (should be out by tomorrow)
LQ: status is - have done more editting and by next weeks meeting we can review the changes
JB: has there been a chance to review the changes
LQ: I am making changes - this TF will need to review
Shane and I will list changes we have done - will report back next week
JS: question was - is there content in this document that is not in the HTML spec?
LQ: do not believe so, but have a verbal confirmation from Steve. F - so believe to be true, but have not had a line-by-line review
<chaals> close action-296
<trackbot> Closed action-296.
JS: which is the concern over the changes that you and Shane have been making - perhaps they should be filed as bugs
<Judy> s/in 2-3 weeks/in 2 weeks or else update provided in 3 weeks http://www.w3.org/2014/Process-20140801/#ACReviewAfter
LQ: exactly, not clear of the value of editing a document that may not be published. it requires major editing
CM: if there is a need to change some of the existing wording and the spec, then having a seperate doc has value
is there significant differances? Do we need to change the HTML docu?
LQ: yes
mostly english language grammar errors - there are also substantive technical errors
CM: will put this into the "suggested doucments to be a deliverable" and see what happens
the work item of fixing the errors in the current guidance is the core, but how we do that remains to see
CM: 2 other action on me. Have posted an email about keyboard access.
<chaals> [adjourned]
<chaals> rrasgent, draft 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/"final"/"final specification" rather than "final report"/ Succeeded: s/cak me// Succeeded: s/reviewed by/passing through/ WARNING: Bad s/// command: s/in 2-3 weeks/in 2 weeks or else update provided in 3 weeks http://www.w3.org/2014/Process-20140801/#ACReviewAfter Succeeded: i/chaals, you wanted to point out filing direct with HTML/scribe: JF Found Scribe: JF Inferring ScribeNick: JF Found Scribe: chaals Inferring ScribeNick: chaals Found Scribe: JF Inferring ScribeNick: JF Found Scribe: chaals Inferring ScribeNick: chaals Found Scribe: JF Inferring ScribeNick: JF Scribes: JF, chaals ScribeNicks: JF, chaals Default Present: [IPcaller], Chaals, darobin, JF, léonie, Joanmarie_Diggs, Judy, janina, Liam, IanPouncey Present: Chaals IanPouncey JF Joanmarie_Diggs Judy Liam SteveF [IPcaller] darobin janina léonie Regrets: Aardrian RichS Found Date: 19 Feb 2015 Guessing minutes URL: http://www.w3.org/2015/02/19-html-a11y-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]