See also: IRC log
<trackbot> Date: 14 April 2015
<trackbot_> Meeting: Web Content Accessibility Guidelines Working Group Teleconference
<trackbot_> Date: 14 April 2015
<AWK> Scribe list: https://www.w3.org/WAI/GL/wiki/Scribe_List
<AWK> Scribe: DanielFrank
<AWK> AWK: Everyone should review the emails on 3.1-3.5 for mobile and respond
<joshue> JOC: Is this open for public review?
MOBILE NOTE TECHNIQUES Andrew: Mobile TF has taken up a number of techniques. We are looking for people to provide comments on the list. Would like initial feedback, to avoid doing a lot of work then having techniques kicked back by WG. Please check out 3.1, 3.2, up to 3.5 emails in the archive and provide comments. Kathy: Haven’t determined which are advisory yet. Please provide comments on that. Every bit of feedback will be appreciated. I[CUT]
<joshue> KW: Yes, it is and people can comment via Github
ACTIVE BRAINSTORM AND MIND MELD
Andrew: We don't have a ton of new stuff for people to review in terms of new techniques.
ty yatil
Even when we have items to review, we shouldn't cancel the call.
There are opportunities for people to discuss WCAG issues they feel are important
Let me throw open the floor
Mark: Question: If we did put some new HTML5 things together, is the group open to looking at those 1 by 1, or should we wait until we have 15-20 to review in a batch?
Andrew: I don't think we are waiting for a specific volume of techniques. If you have 1, 2, 5, 40, that's great.
One of the comments we've received from the charter work is that the techniques seem out of date because of references to old technologies such as HTML4.
We can decide if we want to purge those references
Who is talking?
Katie: Don't break what works in those environments
Andrew: We may need to look and be careful about how those are expressed, in that we may want to have HTML5 techniques separated out
[Katie]? Agree that differentiating those is important?
<Ryladog> Differentiate HTML 4 from HTML 5 from XHTML 1, etc
Andrew: You've hit on another topic, which is them modest amount of confusion that exists around how people can be engaged in WCAG work.
Marc: The issues on GitHub works great, but if I am going to submit something, I am not sure if I am working on the latest copy. How do I stay in sync there?
Andrew:
Probably we need to make sure that that is clarified, not just for you. It's easier if you're starting out with a brand new technique, not modifying something that may not be current anymore.
Marc: Version I seem to have in my GitHub repository, I look on the public site and it's already been updated.
<AWK> AWK created new issue: https://github.com/w3c/wcag/issues/87 (Need to clarify process for working with GitHub for WCAG)
Kathy: I downloaded source tool
who is talking?
<MichaelC> https://help.github.com/articles/syncing-a-fork/
Joshue: Watch out for drop box, doesn't work
<marcjohlic> http://www.sourcetreeapp.com/
Kathy: Think it would be nice to have a tool that doesn't use command line.
<MichaelC> I will admit to giving up and just deleting my fork and reforking, rather than trying to sync it up :)
What I found with source tree is that I can do things from the menu, same as command line?
Andrew: Everything a client done is done with command line commands under the cover.
Marc: General question: Is the github.com Web site not intended to be used as a standalone? Should you have GIT on your own machine?
sorry, who is speaking?
Joshue: You can use the GitHub client in tandem with your browser. But branches can get messy, too. No pat answer.
[I will get the voices eventually]
<Zakim> MichaelC, you wanted to say the above depends on a local clone
Michael: To answer Marc's question, for simple edits directly in the repository you can use command line.
You can't update your fork via the Web interface; you have to have a local clone.
The Web interface is not meant to be comprehensive
<cstrobbe> You can update a patch or a pull request through the web interface; have done that many times.
Joshue: New GitHub client in Mac is you can submit pull requests via that client
<AWK> James: If you are behind a firewall you can set proxy settings in .gitconfig
Andrew: One of the questions we talk about is what we want for some of these techniques documents, what should be our goal for these
There are a lot of people out there who work on techniques, but they don't think of them as techniques for WCAG, and some people who don't send techniques because they don't get accepted and published
One of the big improvements we have made is publishing techniques every six months. One downside is it takes more time. How can we make it easier still, less of a process?
What if techniques existed completely on GitHub?
Andrew: need to be official in the W3C domain
Marc: Someone I've talked to isn't comfortable writing the verbiage that goes on the page
Andrew: One possible way is that if someone submitted a started technique, either by putting in a code sample or by putting in pretty language, they can open an issue asking for help filling in the part they haven't submitted
Loretta, you've gone through this longer than anyone else on the call ...
Loretta: I like the idea of letting people submit code snippets. Getting a live example up can be challenging.
We haven't managed to split this up so people can submit what they are good at.
Joshue: What would those code samples have to be based on?
James: When we accept something
using certain library code like JQuery, would that be OK?
... What about other JS libraries?
Joshue: We can't ignore the fact that people are using different libraries. But then it's perceived we are endorsing these libraries and tools.
Andrew: One of the questions we need to figure out is, if someone wanted to submit a technique about, e.g,, using JQuery to label combo boxes, and JQ uses aria-labeled-by implicitly, do we want to technique to include this is what you need to do?
James: Very good question
Andrew: It's hard to say without it being the specific case. You are trying to create an accessible grid, and it's very complex, all the ARIA roles and states and getting those right. Might be a tremendously long technique. That one I might lean one way, lable example the other way.
Joshue: We have to be aware that people will copy and emulate many of the things we will present as techniques, so what we publish has to be robust.
Joshua: People might want to submit techniques to the working groups using code they've already built using libraries.
Andrew: The risk about the last
part is that we don't want people getting discouraged that we
are asking them to work then discarding it. Clear guidance up
front minimizes that.
... I am hearing that people want some guidance for submitting
techniques.
... Either that or it's just an action.
Kathy: I'm still confused.
<AWK> ACTION: AWK (and Joshue) to think about proposals to increase technique submissions, including the need for code standards. [recorded in http://www.w3.org/2015/04/14-wai-wcag-minutes.html#action01]
<trackbot> Created ACTION-306 - (and joshue) to think about proposals to increase technique submissions, including the need for code standards. [on Andrew Kirkpatrick - due 2015-04-21].
<trackbot_> Created ACTION-307 - (and joshue) to think about proposals to increase technique submissions, including the need for code standards. [on Andrew Kirkpatrick - due 2015-04-21].
Kathy: I might have been one of the people saying GitHub isn't that hard.
<joshue> * +1 to Michael.
Marc My thoughts is that I don't need to keep an ongoing repository if I can just grab the latest, make my change, submit it. Everyone once or couple weeks I could grab it to make a change.
<Ryladog> Let's Have a WCAG2 Git Hub ONLY special online F2F half day meeting...
<joshue> *In principle it is easily there are a lot of CLI snobs
Andrew: ... I do give up sometimes trying to sync a repository, and create a new fork. And then if you were doing that as a practice you could do it all online.
Marc: I was approaching it that way, wasn't sure if I was breaking anything.
Joshue Much of the stuff is undoable, you can't really break it.
Joshue: I would submit pull requests with minor changes, and it gets messy really fast.
<Ryladog> Step by step steps for us to follow - whether it is blessed or not
Andrew: People editing pull requests can't break things but we can.
<joshue> that would be great Eric
Eric: ... I plan to do a high level overview of high level GitHub features at some point. Many people would really want something like that. I need to do some preparation, can't get to it right now.
James: where is my access for pull requests?
Andrew: We are restricting direct
commit editors to those who have gone through training
... I put an action in a while ago to think about some of the
discussion proposals to increase technique submissions
... We have said we need each of those pieces in the past and
we confirmed they are all still true
... Question for the group: There have been some proposals, all
related to charter stuff
... Evaluation and repair tools stuff needs to move to a
different group. That might be WCAG.
... Feedback r.e. some items in ERT. Not tutorials.
Accessibility support DB, list of evaluation tools resources.
Report language.
... part of the question is: Are there things we think about
the ERT group doing that are so important that we would host
them under WCAG?
Kathy: Not thinking about making it go away?
Andrew: Anything is possible.
<cstrobbe> Accessibility support DB is important.
Andrew: Some comments have suggested that ERL should be set aside until there is a standard that ERL does.
<cstrobbe> EARL has been in development for over a decade.
katie: Some support for having the tool vendor actively involved
<cstrobbe> ... There were EARL implementers in the ERT WG.
katie: That is kind of vital for all the things we do. There hasn't been an active participation by the vendor.
Loretta? Unless we were changing the focus and goals of the group
Katie: We shouldn't be taking on
their work
... All the people who develop tools for evaluation and
repair
Andrew: One of the new items of work of interest to W3C members is greater clarity around what you need to do in order to do automated testing for WCAG.
What are the specific tests that need to be done, and right now there is a community group for that, and interest in something more mature for that.
Speaker? If we have a functioning ERT working group, then we should have a joint effort with them. But we can't take it on alone; it's a large thing.
It all relates back to the techniques.
We have to be incredibly careful with the language we use.
What's currently supported in HTML5 and ARIA, and what we want to be recommending, things we recommended that no longer are a good idea, all these pieces are vital to making it work.
People default to using the automated tools to start their testing, to get the low hanging fruit out of the way. Good ERT can get the automated stuff out of the way and then prompt you correctly to test things that can't be found by an automated tool.
An automated tool can be comprehensive, that's a huge effort that ought to be under ERT
Speaker? EARL itself is just the format for reporting accessibility evaluation results, developed independent of what the techniques actually are.
Started around 2005-2006, hasn't been completed yet.
<Loretta> zaki, IPcaller is Loretta
Andrew: Is work on automated testing of WCAG, is that something that needs to be approved by the WCAG group? Should our focus be on the standard and extensions and making sure they are clear enough, or do we need to control that piece also?
Joshue: That's a really, really good question. People who create the abstractions that feed into automation processes need a stable standard to work from. I don't know the answer, but it's worth thinking about and discussing further.
katie: It's within our scope to do that, but how the tool makers go about it, EARL or something else, the content is relevant to WCAG.
Joshue: Should that be our job? We are independent.
Katie: Both groups would profit from having a task force.
Joshue: Better if it wasn't under our umbrella.
Andrew: Certainly easier for us if it wasn't our job
John: Could be education outreach. Challenge for vendors is that WCAG doesn't prescribe certain techniques. We have to come up with tests for WCAG. Just because you fail a technique doesn't mean you fail a SC. Failures are a stronger indicator.
We haven't really been that involved.
Tool from ten years ago could save reports in EARL, but we haven't seen the need to be a part of a group.
Open AJAX alliance has shared tests. You could interchange information between products and tools and expect some shared similarities.
I think there is a need for it, but would need a large number of organizations and a compelling reason for involvement
Katie: Vendors were there in old
days ... Our work would profit from having a group. Whatever
extensions and things we come up with. IBM, Deque, John, your
company, so many organizations out there building these
things.
... We finally have an updated list of people building things.
Get them onto a working group.
Jon: I agree, why haven't people been involved? Hasn't been a market blocker.
No requirement that tool has to be certified, follow this protocol. Language in procurement would be a stronger motivator for vendors to get involved.
When we write accessibility tests, we have automatic, guided automatic. IBM considers a potential violation, an indicator that requires a human to look at it.
Candidate sets: Groups of elements that are likely to be problematic. There are different layers to these things
Katie: Different products would have their own identifiers as to why they are better
It seems that it would be good if they were using sets that had content that WCAG had looked at and said makes sense
Jon: Like a Web site logo program, met requirements defined by a WG?
Katie: Added value is the tool itself would be accessible, and has a higher rate of giving you correct data
Jon: We already feel we are there. Other orgs feel the same way. How do you bring everybody together to work together? Doesn't work with only some of the players there.
Andrew: Certainly there are challenges. That's why ERT has had trouble with EARL last ten years or so?
Speaker? Have to be very very careful before doing something like that. We could impact their ability to publish.
Kristof: A lot of work. Part of the work that needs to be done is that with the tool itself there are many open issues. Part of the issue is populating the database.
<cstrobbe> cstrobbe: is cstrobbe
Andrew: ... I am not clear on what the outstanding work remaining on the tool itself. I was under the impression that it was essentially done, but I am hearing you say otherwise.
Katie: Technology changes, new
stuff needs to be added.
...
<cstrobbe> Here's the issues list https://github.com/w3c/wai-axsdb-web/issues for the Accessibility Support DB http://www.w3.org/WAI/accessibility-support/
Needs to be updated whenever there is a new technology.
Andrew: e.g., no SVG test cases in there. I think you can add new technologies, platforms, tests.
katie: Absolutely you can
Andrew: One approach hinging around the hope that the crowd can do everything, is w3c provides a tool that has utiility, but how much babysitting does the tool need? Ideally none.
Jon: It's even a bigger challenge. If you look at the way that screen readers interact with users, you have all these different ways to access. Even among controls there are lots of bugs. aria-label works differently with different tags, need to test in all these different scenarios.
e.g., JAWS works differently with a button whether there is text in the button (aria-label)
You have to get people to contribute, and there has to be some benefit to the commitment
If people thought the vendors would fix the issues, they might contribute. Right now they are just trying to deal with the issues.
Andrew: questions around
motivation
... So there was just one other topic
... We have added a bunch of items, series of emails onto the
list and seeking thoughts and feedback.
Kathy: It'skind of hard to think of sufficient techniques for best practices.
<AWK> To comment on this document, send email to public-mobile-a11y-tf@w3.org (subscribe, archives) or file an issue in Github. Comments are requested by 26 March 2015. In-progress updates to the document may be viewed in the publicly visible editors' draft.
Kathy: Exactly what you were just saying. These could be advisory techniques, things the task force is putting together under the mobile accessibility notes. Touch access or Bluetooth keyboard access. Determine sufficient vs. advisory techniques. Seeking feedback
What falls under the operable principle, techniques that fall under there for mobile.
Kathy: Might be mobile extensions
Joshue? Having things that really do fall into design and best practice makes me uncomfortable.
James: I am absolutely fine with advisory techniques, not success criteria
Kathy: These aren't SC
Andrew: We need to think about
what the criteria for inclusion is.
... If anyone has any techniques to submit, we are planning get
more techniques out there.
<AWK> trackbot, end meeting
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/When we accept/James: When we accept/ Succeeded: s/What about other/... What about other/ Succeeded: s/Michael?/James:/ Succeeded: s/Speaker?/Joshue:/ Succeeded: s/Speaker?/Marc/ Succeeded: s/WACG2/WCAG2/ Succeeded: s/Speaker?/Joshue/ Succeeded: s/Speaker?/Eric:/ Succeeded: s/kathy: Some support/katie: Some support/ Succeeded: s/Kathy, There were EARL/... There were EARL/ Succeeded: s/Kathy: That is kind of vital/... That is kind of vital/ Succeeded: s/hug/huge/ Succeeded: s/reason/reason for/ Succeeded: s/Speaker?/cstrobbe:/ Succeeded: s/Speaker? ... It's /Kathy: It's/ Succeeded: s/Joshue/James/ Found Scribe: DanielFrank Inferring ScribeNick: DanielFrank Default Present: +3531882aaaa, Joshue, AWK, Marc_Johlic, Kathy_Wahlbin, +1.415.716.aabb, cstrobbe, Kenny, DanielFrank, Katie_Haritos-Shea, Loretta, EricE, Michael_Cooper, James_Nurthen, +1.703.637.aacc, jon_avila, [IPcaller] Present: +3531882aaaa Joshue AWK Marc_Johlic Kathy_Wahlbin +1.415.716.aabb cstrobbe Kenny DanielFrank Katie_Haritos-Shea Loretta EricE Michael_Cooper James_Nurthen +1.703.637.aacc jon_avila [IPcaller] WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 14 Apr 2015 Guessing minutes URL: http://www.w3.org/2015/04/14-wai-wcag-minutes.html People with action items: awk joshue WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]