See also: IRC log
<trackbot> Date: 18 March 2014
<AWK> Marc,
<AWK> /me Marc, we apparently have no phone access, trying to figure that out.
<MichaelC> meeting: Web Content Accessibility Guidelines Working Group Face to Face meeting
<AWK> marc, since we have no good phone service we think that it will be an exercise in frustration for you to try to hear all of us via a mobile phone
<AWK> We can just assign a bunch of actions to you!
<Joshue108> http://www.w3.org/WAI/GL/2014/03/ftf-meeting#agenda
<JF> sribe:JF
<JF> scribe: JF
awk: enough seats in the room now, round-table intros
Areminder that scribing is a shared effort :)
a number in the room are part of the Eval Task Force
shadi: EVal TF met yesterday to review comments
deadline for comments was end of Feb
good comments surfaced, but nothing big in terms of "Issues"
hope next publication will be the first Note
hoping to release by June timeframe
also doing test runs
have done that previously
running internal testing side-by-side with the TF evals
now hope to do a more formal review, tracking via a website
imitating the Formal Candidate process
a few issues to discuss, including increased complexity and the scoring issues
the later being something of a bigger issue
<shadi> Review teams: Do we recommend that website accessibility evaluations are more effective with a team of 2-3 evaluators, as opposed to 1 only?
Shadi: there is a document (2005) from WAI taling about combined expertese
notes that an evaluator requires mutliple expertese
suggests that a single evaluator may not have the full set of skills
<MichaelC> Review Teams for Evaluating Web Site Accessibility
may have gone a bit overboard in the recommendation - feedback suggesting it is too heavy
so want to see what is the way forward. what is the common practice today?
clear that one person *can* do a review end to end, but note that a team is better
<Joshue108> JF: There are many organisation where it is only one person.
awk: reminds that there is the irc channel and queuing
<shadi> http://www.w3.org/TR/WCAG-EM/#teams
JO: do we have any signs that more is better?
<shadi> http://www.w3.org/WAI/eval/reviewteams
KW: document calls for "teams" - may be a team of 1, or a team of multiple people with individual skills
the document suggests that 1 isn't enough (not directly), and so want to be sure that nuance is clarrified
JO: important distinction that an individual can have multiple skills
LS: explanation makes sense, but it needs to be clear in the document. For example if it says team, we need to clarrify
KW: talking about removing the term team altogether, and instead note that it could be more than one - combined expertese
<Joshue108> +q
DM: agree with Kathy. as a 1-person consultant, experience shows that 1 can evaluate - many sites only require one
KW: the term is combined expertese
<Joshue108> +1 to core competencies
DM: perhaps include core-competancies
AWK: even with one person who is highly qualified - humans make mistakes
Gregg V.: the eval team requires expertise in all areas. can be one or many
the concern is that people go in with a certain perspective (eg. blindness expertise) and thus skews the report form that perspective
DM: the term team is problematic
JO: agree, one DM may have more expertise than a team of 5 with less experience
shadi: seems to have concensus. not time to do the word-smithing now
but it seems clear that requestors need to have an understanding of the core competnancies, and aks for that, not numbers
shadi: the issue is the tension between referencing techniques versus the fact that the techniques have been promoted to normative in certain locales
<Joshue108> +q
need to keep a polite distance. Be aware of the techniques, (don't want to undermine the work of WCAG), but leary to appear to promote the Techniques as normative
<shadi> http://www.w3.org/TR/WCAG-EM/#step1d
<shadi> http://www.w3.org/TR/WCAG-EM/#step4a
awk: how much of that tension results around confusion between normative and guidance implied in the techniques?
one thing we've noted is to provide additional clarrity around the techniques - what does it mean when you fail a technique?
shadi: yes, things have gotten better. however that is also the question. the pressures come from external locales
the techniques are being referenced as "normative" in for example M376 (european of Sec. 508)
shadi: we do want the work recognized and used, but remain concerned that too much weight is being given to the Techniques
JO: part of the issue is that we get lost in our own jargon
perception is that outside of us, everyone sees what we do as bing normative
not sure how to undo that perception
<AWK> Clarification: M376 is the mandate that resulted in EN 301549
<AWK> EN 301549 is the standard
LGR: not sure if there is real confusion, but rather it is easier to evaluate against specific techniques when expertise is lacking
not sure is we can fix this at our end via wordsmithing
the real danger is that if something works, but is not in the "Official Techniques" that it will be rejected
Shadi: there have been some useful resources like the FAQ that we need to elevate, to reinforce that the Techniques ar enot Normative
LS: confession - took a long time to understand what normative really means
<laughter and concurance>
so we need to perhaps use clearer language
LS: another way may be to use a different template: the techniques have an appearance of "official"
perhaps use a different font
JO comic sans (laughter)
<Joshue108> JF: We don't use colour alone!
LS; but use a different color (purple maybe)
gregvan: use color reduntantly as it is very useful for cognitive
(agreement)
but Loretta makes a good point - using the "standard" shifts the blame/responsability
if authors use what is specified in WCAG then they can't be blamed
believe the term we need to use is "Requirement"
<Joshue108> +q
the other term would be "approved option"
GregVan: so focus on the requirement.
khs: a huge part of the training we are doing is the idea around the design of WCAG, by being able to be a standard that can last through a number of tech changes
thus the only requirement is to meet a, AA, or AAA
but that the techniques can grow with technology - that the Standard can grow - by design
JO: want to +1 Katie
we need to refocus on the Success Criteria
and less so on the techniques
KHS: one more thing. even folks in this biz ...
a major eval tool company stated that the Standard is seen as a guideline
JO: need to move along
... this is a good conversation, but we need to watch this space
shadi: next issue is on the similar line
just a report back - throughout the work of EM, we feel there is a strong lack of support for evaluators - taht the techniques are written from the author perspective only.
there are different checks in the Techniques to address this
shadi: the feedback is that a point-by-point evaluation method would be useful
JO: acknowledged
shadi: we went point by point to look at that
JO: good feedback and interesting to hear the update
surprised to hear the eu standard point to the Techniques
JO: just to close the loop - what can the group do to help EM going forward?
<AWK> AWK: Just to clarify that EN 301549 doesn't point to WCAG techniques as required, but it does reference the Evaluation Methodology in an informative way.
shadi: in terms to evaluation support - for example a quick reference
<Joshue108> ACTION: Working group to clarify the importance of the SC over techniques, the use of failures, how to use the quick ref doc for evaluators. [recorded in http://www.w3.org/2014/03/18-wai-wcag-minutes.html#action01]
<trackbot> Error finding 'Working'. You can review and register nicknames at <http://www.w3.org/WAI/GL/track/users>.
to have these created with the evaluator in mind, and not just the authors
shadi: thge other peice is more guidance on a11y support
JO: that is a much larger discussion, on the agenda for later today
<??> more practical guidance
<MichaelC> ACTION: joshue to get working group to clarify the importance of the SC over techniques, the use of failures, how to use the quick ref doc for evaluators. [recorded in http://www.w3.org/2014/03/18-wai-wcag-minutes.html#action02]
<trackbot> Created ACTION-242 - Get working group to clarify the importance of the sc over techniques, the use of failures, how to use the quick ref doc for evaluators. [on Joshue O Connor - due 2014-03-25].
<Joshue108> ACTION: WCAG WG to clarify a11y support [recorded in http://www.w3.org/2014/03/18-wai-wcag-minutes.html#action03]
<trackbot> Error finding 'WCAG'. You can review and register nicknames at <http://www.w3.org/WAI/GL/track/users>.
<MichaelC> ACTION: joshue to get WCAG WG to clarify a11y support [recorded in http://www.w3.org/2014/03/18-wai-wcag-minutes.html#action04]
<trackbot> Created ACTION-243 - Get wcag wg to clarify a11y support [on Joshue O Connor - due 2014-03-25].
MJM: need both a quick list and a comprehensive document as well for evaluators
when you have testing going on there is a different between unit tests and holsitic tests
shadi: it is theoritically possible that a "page" could meet WCAG for one AT, and another section failing for another AT
... this is a real world problem, and need to know what tools can solve this
<Joshue108> JF: So you could have a page that works apart from embedded video.
<Joshue108> GV: Then it fails
shadi, no the top page would work with one set of AT, and the bottom part of the page with another AT, then it passes
did not note that the Guideline does not state that the whole page is required to be accessible
<Joshue108> ACTION: Josh to clarify how conformance requirements relate with SC and evalution methods. [recorded in http://www.w3.org/2014/03/18-wai-wcag-minutes.html#action05]
<trackbot> Created ACTION-244 - Clarify how conformance requirements relate with sc and evalution methods. [on Joshue O Connor - due 2014-03-25].
shadi: survey suggests thtis is a problem
awk: would be interested in seeing the survey results, and we can address this again
LGR: interested to see if there is a gap/loophole in our documentation that is introducing this confusion
<AWK> ACTION: Shadi to look up what the past survey was that indicated that pages could meet accessibility support requirements with different AT for different parts of a page [recorded in http://www.w3.org/2014/03/18-wai-wcag-minutes.html#action06]
<trackbot> Created ACTION-245 - Look up what the past survey was that indicated that pages could meet accessibility support requirements with different at for different parts of a page [on Shadi Abou-Zahra - due 2014-03-25].
shadi: next issue is scoring
scoring in whatever way (different approaches exist) - is frequenetly asked for and done in practice
but there are many concerns here, and it is controversial
accessibility is not quantitive, but qualitive
have looked at quality criteia for the metrix
and nothing realy exist
question: do we stop, as it is too difficult/controversial, or do we attempt to pursue further?
<Joshue108> +q Lorettta
with the understanding that it would not be perfect
shadi: one motiviaiton is to see ("track" progress)
LGH: so the score would translate to what? more people can use my website?
shadi: it is more about tracking progress and "competitive advantage"
JO: it ties into the buisness case nicely as well
GregVan: one reason to not use scoring is that it violates WCAG
having a measure of partial conformance is not allowed
it there is a need to do tracking you can always say that you meet X number of Success Criteria
problem can become that if you start to accept "85%" successful, you eventually lop off 15%
KW: what about using a more complicated weighting system
GregVan: we have A, AA, AAA
if you are skipping A's and doing AA's then that is a problem
LS: agree with GReg, but...
it depends on whether we can do it well
if we can do it well, will usability increase with this, then...
so if we can make sure that the scoring is well done
for example, a submit button that doesn't take focus is pretty serious, yet an image in the footer without alt text is less urgent
shadi: the question is then, do we pursue or not?
awk: not optimistic that we can navigate a scoring mechanism
this has been tried many times over the years
that said, it is reasonable to have a dashboard on accessibility
relasted against bugs.
for example if you have zero bugs against AA in a bug tracker, then that is a score
wry however that it becomes a rat-hole quickly
JO: abstraction that WCAG is a binary pass/fail
some will say we will do all of A, and some of AA
LGR: biggest issues is that when you start scoring changes the dynamic
teams start working towards percentages, and not the total issue(s)
<Joshue108> +q to say we need also to support good design aesthetics.
KHS: in the real world of remediation and development, people need a prioitization plan
even though there is A, AA, AAA where to start?
recommend tackling the A's first, then the AA's etc.
as a broad plan
<Joshue108> JF: Scoring is required, bugs are prioritiesed.
<Joshue108> JF: Bugs are dealt with like this, from most important to least.
<Joshue108> JF: We need some recomendation on prioritisation
<Joshue108> JF: We need a way to distinguish fatal from non critical errors
GRegVan: there is a difference between highlighting a plan of attact versus scoring
shadi: this isn't the issue, rather to measure progress over time
LS: there is a desire to say"we are the best"
if you can't do it well (this is an improvement on usability) then fine
but don't let dashboards say "this is blessed based on WCAG
KW: another option is that there is A, AA, AAA - people can track the number of issues against each
JO: harin that there is the need
shadi: trying to rename this or refocus
<Zakim> Joshue, you wanted to say we need also to support good design aesthetics.
JO: one of the things is to try and tie this up - people who wear different hats and bring in the views there
noting that there are still cracks
JO: wrapping up, we need to have something that is static - that it also recognizes good, beautiful design. last thing we want is "ugly accessbile"
awk: appears that we don't have time for a demo of the accessiblity support db
... we are running about 30 minute behind schedule
<AWK> Taking our break early due to excess verbosity and JF's tired scribing fingers
<AWK> Scribe: Loretta
Judy Brewer: thanks Adobe and ETS for hosting this meeting
<MichaelC> Lisa´s slides
Cognitive and Learning Disability Task Force - joint task force of WCAG and PF
Important to remember that cognitive disabilities are localized. Affects only some skills, not all cognitive skills.
Largest group of people with disabilities have cognitive disabilities.
Growing - # of people with dementia is growing.
Usability of web sites goes down for people from age 25.
Many systems have become a lot more complex. e.g. Web of Things.
TV, phone system are much more complicated to use.
This bars people from getting basic information.
TF plan: review existing techniques to see how they could be improved.
Users and abilities -> gap analysis -> techniques.
working on gap analysis now.
Looking at 2 sets of things: user groups and technologies.
When you put these together, hope to reach new conclusions.
Phase 1, because there are so many types of cognitibve disabilities.
<AWK> Dyslexia Dyscalculia ADD/ADHD Brain injury, aphasia Non-vocal Dementia Down Syndrome Autism
Cognitive disabilities are very diverse, sometimes diametriically opposed.
THere are groups being missed out, but trying to look at groups with the greatest variability possible.
What might proposals look like?
1. Simple techniques that are good for everyone. For instance, Windows has F1 for context help. This is a really useful tool.
There may be techniques that are broad, relatively simple to do.
There are also techniques for different user groups.
<Joshue108> + q to ask can we do some work to identify techniques that have common treads with all user groups but have a cog a11y focus.
The Save button and the Save icon. If people with dementia are literate, the Save button is important. For someone who is non-vocal, a Save icon may be needed.
<Joshue108> +q to ask can we do some work to identify techniques that have common treads with all user groups but have a cog a11y focus.
<Joshue108> +q to ask can we do some work to identify techniques that have common treads with all user groups but have a cog a11y focus.
Something like IMS lets different user groups find different resouces.
Need the metadata to find the best resources for them.
Current metadata only supports physical disabilties, not cognitive.
Customizing environments for people.
Techniques structure: finding the right techniques is one problem in WCAG.
People with different cognitive disabilities have different needs so some techniques are different for different groups. This led to techniques for cognitive disabilities either to be advisory techniques or to be at level AAA.
e.g. 2.2.5 is valuable for everyone with cognitive disabilities.
<Joshue108> http://www.w3.org/TR/WCAG20/#time-limits-server-timeout
if you lose all your data because your session times out, it is a bad thing for all people with cognitive disabilities.
WCAG also wants author freedom, and this also impedes techniques for cognitive. e.g. under guideline 2.4. is making links visually distinct. But because it changes the look of a page, it is advisory.
Suggestion: do we want a tag for cognitive within WCAG?
We've seen people put WCAG techniques into legislation, but advisory techniques won't be included.
Many people want to make their web site accessible for cognitive disabilities, but don't know how.
Time limits are universal, but it is AAA. We don't want to change WCAG, but how can we bring more visiility to techinques that help cognitive?
There are so many advisory techniques. If you want something like level A for cognitive, how will people create that checklist, and understand which advisory techniques are important for cognitive.
Maybe create a Note that is just a checklist.
Also the more important vs the less important.
Maybe also create some leveling for techniques for cognitive.
We may want to make some changes to tchniques so they address both physical and cognitive needs, e.g., alt text should be simple text.
<Zakim> Joshue, you wanted to ask can we do some work to identify techniques that have common treads with all user groups but have a cog a11y focus.
e..g. given a picture of a sign that says "normative text" should the alt be literal or a simpler version of the language.?
Josh: excellent work; very ambitious work.
... would be great to identify the WCAG techniques that are particularly relevant.
<Zakim> MichaelC, you wanted to suggest we consider techniques approaches holistically across all the TFs - time later today allocated to start that
<JF> notes that there is HTML5: Techniques for providing useful text alternatives around ALT text - and all of its nuances: http://dev.w3.org/html5/alt-techniques/
Michael: I heard you talking a lot aobut the techniques, including how they are not meeting the needs of cogntive.
... let's consider this holistically, since I think the other Task Forces are doing similar things.
... can we generalize our solution, i.e., rather than a special tag for cognitive, do we need a general tagging scheme.
Tim: are you proposing defining a new level of conformance.
<Lisa_Seeman> http://www.w3.org/WAI/PF/cognitive-a11y-tf/wiki/Main_Page
Lisa: right now, we are doing gap analysis.
... put everything on the wiki. can sort through later.
... we haven't come out with a road map. We are just starting explorations.
Katie: TF is trying to draw on existing expertise.
... Save button vs icon is a good example, that there are not universal solutions for cognitive.
... it is not intuitive. Need the people who have done the research involved.
Cognitive breakfast tomorrow morning at 7:30. in Lael's
To write in the wiki, you must be a member of the task force.
JF: how can non-TF members contribute or make comments?
Lisa: there is a discussion list for the TF, and anyone can join that.
Michael: any WCAG member can join the TF.
<Zakim> AWK, you wanted to say that the TF has two main benefits - how to help address cognitive now, and identifying issues for future consideration
AWK: 2 benefits from this and other TFs: determine how to improve what we offer within the current framework/guidelines, and what issues should be considered for any future work on the guidelines.
Josh: could the TF produce a matrix of techniques and success criteria that are specifically useful for the user groups you are studying?
<Lisa_Seeman> http://lists.w3.org/Archives/Public/public-cognitive-a11y-discussion/
<kw> http://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Main_Page
TF started by taking a good look at what resources are currently out there (WCAG and non-WCAG)
BBC, IBM, work that has been done on mobile, to see where we are today.
<Lisa_Seeman> Discussion list for general issues of cognitive and learning disabilities accessibility.
That list is still growing.
Looking at publishing all or parts of that.
Also more gap analysis.
Looking at BBC guidelines and doing gap analysis against both WCAG and UAAG.
This is in th beginning stages.
Also going through all of the WCAG techniques and Understanding documents and identifying areas where they need to be updated for mobile.
e.g. adding keyboard examples, looking at places where working might need to be updated.
What does keyboard access mean for mobile?
<kw> http://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Keyboard_Access/Modality_Independent_Control/IndieUI
Gregg: Most or all phones allow bluetooth keyboards.
Kathy: but how they work depends upon the device.
Gregg: I worry that people think that phones don't have keyboards, so that means they can't meet that provision, so we should remove the provision.
Kathy: We aren't going that way; that idea hasn't even come up.
Gregg: I have heard suggestions that the requirement should be changed to keyboard accessible or gesture accessible. But gestures don't meet the needs of all people who use keyboards.
Uplevel - descending into the technical details..
TF would like to continue this discussion over the next few weeks. Have invited some people to come talk with the TF.
Then will summarize the discussion and bring it to the WG.
UAAG is also working on this, and TF will also take this info there.
Key things: gap analysis, which techniques need changes, which techniques should be added, both for mobile web and mobile apps.
Also discussed having an easy way to get to the mobile techniques. How does something find all the mobile examples in general techniques, etc.
Create separate techniques, like for PDF? But it is still HTML. Similar challenges as for the cognitive TF.
<kw> http://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Draft_WCAG_Techniques
WIll be converting this info into a matrix.
At that point, TF will bring their plan to the WG for review before starting work on techniques.
Gregg: might consider adding mobile sections to existing techniques, rather than writing separate mobile techniques.
Kathy: looking at which need modifications vs writing new ones.
Gregg: people may think only the mobile techniques apply to mobile.
Michael: there are 2 tasks. How is the current structure not working for you, and what techniques are missing.
<Zakim> MichaelC, you wanted to talk content and structure of techniques
David: we are talking out web applications at an http address, right?
Kathy: both web applications and mobile native applications.
Judy: there is a continuun of apps from native to web (wrapped apps, hybrid apps, ...)
With HTML5-centered open web platform, you can use HTML5 and other specs to tap into most of the capabilities of the device.
Judy: There is a much larger space of things that is relevant.
... Analysis of what parts of WCAG are relevant to mobile has always shown a high overlap.
Paul Adams: I do this all the time at Dequeue. Apply WCAG where it works and it is mostly everywhere. But most people don't understand how to apply WCAG to native apps.
Gregg: WCAG to ICT on the criteria level, but don't have techniques.
... there would be LOTS of them.
... Judy, does the W3C want our WG to wander outside of web content?
Judy: the matrix is from our Mobile Czar. I've been pushing him to push that further, and that is one of the questions we are debating internally.
... WAI will track that, but will also identify the relevance, like WCAG-to-ICT.
... But we had not done the exercise of looking from the mobile environment back to what is needed. Happy that the TF is tackling this.
AWk: need to discuss division of labor between TF and WG
TF is resource constrained, especially compared to the number of techniques we would like to have.
AWK: great that we could get so many out in the latest update.
... but techniques bounced back and forth between WG and TF a lot.
... we are trying to figure out the role and balance of the TF
... : TF members have a lot of experience writing techniques.
... Greater engagement among the WG members in writing techinques will also help that process.
<Zakim> MichaelC, you wanted to talk history of techs tf
<Joshue108> +q
Michael: history of the task force - created as a joint TF between WCAG and PF.
PF needed ARIA techniques, and wanted HTML5 techniques.
ARIA has matured. Accessibility in HTML5 has improved. PF needs for the TF are less strong.
Josh: thanks to the TF chairs and members for all the work that has been done.
James: thanks to everyone who has worked on techniques. Everyone has been very patient with the back and forth.
AWK: or we change the way we think about the tchniques, sometimes several times.
Michael: is there a plan to close the TF?
AWK: no, but there is a recognition that there is a lot of technique work that needs to be done.
It isn't realistic to expect that work to be magically done by some separate group.
AWK: part of what we need to figure out is what the role of the TF should be.
James: All TF members are in WG.
Josh: We have potential duplication. Need to eliminate some of the churning, and focus the attention of the core WG on this.
James: Yes, but don't know how this is going to work.
AWK: As we look at tracking techniques, etc., some of our discussion this afternoon may help us figure this out, or whether there isn't a role for a special group.
... Maybe TF handle sprioritization or tackles hard problems?
James: maybe the standard meeting time is a workshoip time to help people who are struggling with writing techniques. No separate surveysk etc.
Gregg: break it down to technique definition, technique writing, technique review. This might let people work on the aspect they are comfortable with.
Katie: great idea.
Josh: There are lots of technique authoring tips that are not domain-specific.
Judy: Agree that there is an intimidation factor in writing the techniques, but we want to build capacity within the group of people who are interested in this.
... Would like to see a "Learning how to write techniques" session.
... And really want to increase the number of people who can write tchniques.
Paul: Making it faster and more efficient. All I did was write the live example. I'm happy to do that for any techniques (provide live examples for people).
... I';m not as good at wording the technique, but I'm happy to learn.
<Joshue108> +q
AWK: We talked about the new wiki page - dashboard for where techniques are at. Different people are good at different parts of the task.
... We want this to be a working group, not a review group of other people's work.
... We want to encourage everyone to give technique writing a try.
... Modifying an existing technique is an easy way to get started.
Josh: We need to codify the logic used in technique test procedures.
Michael: The accessibility database support people depend on that.
<Joshue108> ACTION: Josh to work on codifying the logic used for technique test procedures [recorded in http://www.w3.org/2014/03/18-wai-wcag-minutes.html#action07]
<trackbot> Created ACTION-246 - Work on codifying the logic used for technique test procedures [on Joshue O Connor - due 2014-03-25].
Writing WCAG Techniques notes: https://docs.google.com/a/google.com/document/d/1-EQ6Z7LguQevaHYsJL-pCiQARgspUaGe5ykKGeF0aNQ/edit
<kw> scribe: Kathy
<marcjohlic> ^ I'm not able to access that URL (username and password)
<kw> Loretta: mostly historical information and there may be better ways to. This is what we learned along the way
<AWK_> LGR: Techniques provides specific examples of the principles
<AWK_> LGR: provides a way to convey best practices
<kw> Loretta: the techniques document helps people by providing specific examples, documents not best practices that does not meet WCAG
<AWK_> ... also a way to convey "not-best" practices that still meet WCAG
<kw> Loretta: we should be reinforcing best practices
<kw> Loretta: the issue is should we include item that are not best practices but meet the success criteria
<kw> Loretta: debate will be should we be telling people that
<kw> Loretta: we should decribe the outcome
<kw> Lortetta: want the technique to be useful for people who did not develop the page
<kw> ... trying to write the description and test procedure based on what you can see on the page
<kw> ... sometimes have awkward language, need more plain talkers
<kw> ... role for many skills
<kw> Standard write up, set of instructions and templates available
<kw> the links are in the document that Loretta will distribute
<MichaelC> Techniques starter page
<Joshue108> https://www.w3.org/WAI/GL/wiki/Technique_Instructions
<MichaelC> Technique Instructions
<kw> Loretta: overview of the different sections
<MichaelC> Technique Template
<kw> Status section - working group only; details on the history
<kw> ... could include links to the survey and the comments made
<kw> Applicability - there is no much to say in some cases but some are complex; this section will be in the final document
<kw> ... capture when it is applicable and when it will not apply
<kw> ... call out what success criteria is it relevant to
<kw> ... may need to be combined with something else
<kw> User Agent and AT Notes - added to document AT support
<kw> ... list all combinations that were tested. Based on what was available to test
<kw> ... this section gets out of date
<kw> ... snapshot of what is true at the time of writing the technique
<kw> AWK: this section can be updated; but it would be great to link to the accessibility support database
<kw> AWK: did a quick test and there were 66 different combinations that received feedback on
<kw> Loretta: we were worried about this when WCAG came out and now it is worse
<kw> ... more combinations than ever before
<kw> ... for new techniques we should add information for the working group discussions
<kw> ... maybe this becomes part of the status section
<kw> ... if we write things down about this, we should date them
<kw> ... all the testing WG does is in English, so accessibility support is not covered in other languages
<kw> ... probably going away
<kw> Description: what is this technique
<kw> ... think about a developer who wants to solve the issue and give enough details
<kw> ... often see "the objective of this technique is..."
<kw> that is the abstract language; objective
<kw> ... should describe how
<kw> General Techniques it is hard to go into more detail
<kw> they are catch all
<kw> ... specific techniques are easier
<kw> to write
<kw> Model of adding examples does not work
<kw> examples are important but are not the techniuqe
<kw> also include information on best practice and label it as such
<kw> Examples: useful for helping people understand
<kw> ... lots of people will cut and paste examples
<kw> ... we need to be careful about the model
<kw> ... if you code to show full conformance, then the example becomes very large
<kw> ... needs to be a balance
<kw> ... current compromise is to put a snippet on the page and the live example has the surrounding code
<kw> ... live examples need to be compliant
<kw> David: what about just highlighting the change
<kw> ... things are getting more complex
<kw> ... may help users to quickly see
<kw> Lisa: worried about in the case of ARIA where you don't have the full examples
<kw> Lisa: people will leave out parts
<kw> AWK: will pick up this conversation at 4:30
<kw> Loretta: the right answer is not clear cut
<kw> Josh: issues around complexities
<kw> Loretta: historically we did not have live examples but shoudl be included moving forward
<kw> ... counter example should not be included
<kw> ... failure example is sometimes easier but should not be included
<kw> in this section
<kw> Resources Section: link to other sites where you get more good info
<kw> ... also list related techniques
<kw> ... or a relevant failure
<kw> Test Section: 2 parts - procedure and expected results
<kw> ... steps to see if the user has implemented it correctly
<kw> ... it is hard but very important
<kw> tempting to write based on the accessibility support
<kw> much better to write a test procedure without relying on specific things
<kw> Write them as clear
<kw> ... sometimes it better to be redundant
<kw> Failure Techniques: document common failures
<kw> ... people may think these are good but are common things that found
<kw> stronger than techniques
<kw> ... need to be careful in writing these
<kw> ... some items may not be absolute failures anymore with changes in technology
<kw> ... tied to accessibility support
<kw> Gregg: they are good but if they get too complex then not useful - keep those that are crisp and useful
<kw> Gregg: need to document that some items may not be included
<kw> Lisa: may lose that messaging, these are good for pointing to these in testing
<kw> Josh: not as clear
<kw> Loretta: hard to write
<kw> Paul: accessibility anti-patterns
<kw> ... before and after demo is good
<kw> Loretta: good if people picked up tutorials around this
<kw> Paul: UX is already looking at this
<kw> AWK: does it help to write procedure first?
<kw> Loretta: I do not limit myself to writing in order
<kw> depends on the technique
<kw> ... what ever gets you going on it
<kw> place on iterating for the technique
<kw> sometimes it is just adding in pointers or collections of information
<kw> ...maybe adding in DRAFT into the title when researching the techniuqes
<kw> ... we all bring different strengths
<Lisa_Seeman> http://accessibility.athena-ict.com/aria/aria-examples-index.shtml
<kw> Lisa: I have examples that can be used
<Lisa_Seeman> http://accessibility.athena-ict.com/aria/aria-tests-index.shtml
<kw> Loretta: make more progress if we were able to get the interaction going with writing the techniques
<kw> Kathy: can we have multiple people assigned
<kw> AWK: yes
<kw> AWK: maybe we spend some time to unstick ourselves
<kw> AWK: space for adding need help on the WIKI page
<kw> AWK: still struggling around the details of Github
<kw> AWK: right now use the WIKI
<kw> AWK: goal is to make it more user friendly
<kw> AWK: XML makes it difficult
Writing WCAG Techniques: https://docs.google.com/a/google.com/document/d/1-EQ6Z7LguQevaHYsJL-pCiQARgspUaGe5ykKGeF0aNQ/pub
<Ryladog> Scribe: Katie Haritos-Shea
<Ryladog> ScribeNick: Ryladog
<scribe> Meeting: WCAG Working Group F2F Afternoon Session
<scribe> Chair: Andrew Kirkpatrick
<AWK_> https://www.w3.org/WAI/GL/wiki/Post_WCAG_2
<MichaelC> Post WCAG 2 issue collecting list
AWK: Post WCAG list see URL
<Loretta> (Third time's the charm: Writing WCAG Techniques https://www.w3.org/WAI/GL/wiki/Writing_WCAG_Techniques_-_Notes
AWK: The big question for us is - our charter is almost done, since it is for 3 years - do we want anymore NORMATIVE work?
... We have been using this Wiki Page - Post WCAG to just dump issues. Articles and blogs and metadate, etc, yada yada
... One thing we need to do is a structured way to address these problems. Do e need a new version of WCAG or should we work with what we have?
<Joshue108> https://www.w3.org/WAI/GL/wiki/Post_WCAG_2
AWK: Currently there is no plan for anew version of WCAG. We would need very good rationale if we do.
... Where did all of these artciles come from?
GV: Some of them are from years ago
JO: I threw abunch of things in there
https://www.w3.org/WAI/GL/wiki/Post_WCAG_2
JO: of progression, feel free to edit it
GV: Maybe we need more information in the Understanding Doc - maybe sort by WCAG doc
<Joshue108> <discussion on cognitive issues and a11y>
<Ryladog_> ScribeNick: Ryladog_
LGR: We had this split between WCAG and UAAG and those bounderies continue to blur
GV: We got into this in Web2ICT and what is Hybrid. We need an entirely different kind of car
<AWK_> LGR: We should hear from the people trying to implement WCAG 2.0 and what challenges they have
GV: We need to solve that we are going to the hybrid, now they want you to bring things down from the cloud. In WAG2ICT for books - we ran into this
JF: We have OS that use HTML now
<Zakim> Judy, you wanted to comment on WAI 2020
GV: We need to invite Rich S. to talk with them about where tech is gong next...
<Joshue108> +q
JB: One assumption for future possibilities - for now WCAG 2 is stable - we also assume that forward
back
JB: we beleive is stable because all of the forward compatability work that went into WCAG. We will need to work more closely with the other two GL - we may need to do something combined with those gourps as WAI 2020
... One thing we wold love to have wold be talks about what WAI 2020 might need, Thinking way ahead, planning way ahead. It may be that WCAG may need to take the lead on that combined context
... What are the immediate reflections are of those in WCAG forthis WAI 2020 for way in the future. We understand that it will take a lot of time to get consensus for a future vision for us
... Now in 2014 - we have noticed as soon as someone talks about updating WCAG there is this panic cycle - it is too much work to update a stable standard will be underestimated
JF: Propbably by a factor of 10
JB: We are very happy withthe Techiques layer that allows for updating. WAI 2020 is not that far away
... but it is not. It enables folks to think ina very calm way about thefuture. Possibly inmodules. Maybe as we have better planwe may name it something else
... It is to hard to stricly subset this stuff. We need a broader brush. Jeff Jaffy the W3C CIO we need visionary thinking, you have an opportunity to invite dialog on the future
GV: Not 2050, but 2020 is the future within grasp
JO: The probem though is the dirth of techniques. The BBC created a lot of good mobile techniques. We are behind on a set of guidelines. Maybe it is time for a fresher look
... There is this need for stability and iterative changes
GV: there is nothing preventing us rightnow ofcoming up with more techniques. If you need more techiques - do not change the guidelines b/c folks will work on that
... In WCAG2ICT almost all of the WCAG SC were good and applicable as princples to address software and documents
... How do you apply these Princples with the various Technologies
JF: It is based on princples will never change
JO: But people look at WCAG with different hats - for different audiences
<Zakim> MichaelC, you wanted to say technology evolution has created new a11y problems - even though the principles are the same, new success criteria are needed
MC: I agree with JF, but the technologies are chnaging - he SC may need to be changing - not sure that we need new standard yet or not
DM: It doesnt seem like anything new that content not seperated from presentation. I do not think if WCAG 3 cam out folks might not freak out. I think it is possible to have a WCAG 3 in 2018 or 2020
LS: GL 3.1 make it Understandable, at Level A and/or AA put in Language tags. That is a guideline that needs to be filled in. Like definitions forJargon is AAA a that is Normative.
... The only place I can see where I can put in new Cognitive techniqus
JO: Maybe you will not needs levels for Techniques forCognitive
MC: WCAG is used to push movement on people, and you are saying as is - there willbe no push for the congnitive without the Normative push. Our only option now is AAA
GV: So you could put techniques under Guidelines
LS: But techiques are used to justify SC
... Rich will be talking about alternative versions I guess - for that the techique can be stronger - you are less worried about Author Freedom
JO: Give us your new mapping best pratcice, that is an idea- thenWCAG can look at that
JB: I think that might create more confusion. In ShenSzen the Roadmap is really good. It is better to keep it associated with WCAG mapping. We do ot want to slow down the conversation.
... Towards the future there is going to be all kinds of ideas - it may be harder if folks are doing their own version.
JO: For mesome loose thinking for a WAI 2020
JB: Someblue sky space wold be pretty god, but we will need to frame it well. Within this - lets get a bunch of people thinking about this using these parameters.
JO: I am talking about a kind of 'note to self'
LS: Basically the task force is to create a Roadmap - it can be a bit more blue sky. If you are thinking of 2020 - look at things like 'exposing structures' (and things like that) that I thinkare brokeninthecurrent version
GV: Unpacking. It took so many years to get consensus on this it will take too many years to fix
... You will have to have the same old discussions....but inthe end it all turns out the same. But you have a wholenew group of people
... 2020 for a topic that spans the WAI groups, - the xtech list. WCAG only applies to HTTP. People think that is a web page and it is not, it uses other protocols. The future will have more of these blended apps and the user does not even know the difference
... That is going to bethetrend. Thisis what weare going to have to address - these merging techologies
... Google, Apple, Microsoft are all doing this. We have to move away from HTTP only
KHS: We are making ourselves irrellivant if we dont
GV: One other thing with GPII - IUIG you cant get companies to giveyou an API (Because they are worried about you stealing their code). But if we could give the companies the iUIG to those companies to provide as impleinterface OUT of their app
... Then you could say if you can make it work with this generator - yo may have greater accessibility than we do today
... Can we come at this thing from a very different perspective - take the weight off of the authors
LS: Adaptable interface
<MichaelC> W3C work in this area is Model-based User Interfaces http://www.w3.org/2011/mbui/
GV: Some are worried about too computer. We need to allow companies to do accessibility and keep control of their content
<AWK_> The WCAG working group is collecting requirements for a possible future version of the guidelines. The group is not chartered for normative work at present. Any work on the guidelines themselves will only occur once a clear need is established and would not be finalized for many years.
AWK: We are not yet looking for broad public input on this. So use our official Talking Points statement - use this - please do NOT talk about WCAG 3, WAI 2020. he talk is aroundmaking the web better
... Please no tweets and facebook posts....please use the talking points
<GreggVan> s / stealing their code/ stealing their functionality and selling it under other cover/
LGR: History - back when we first talked about requirements. A mansaid make sure whatever we do woll be testable, that their might be regulations built around these. I think the thinking about WAI 2020
... The discussion is insomeways going to be the same. Got to leave the assumptions.
AWK: People brought in their experience with WCAG 1 to improve WCAG 2
DM: Yes that experience will be coming in soon for the US and Canada
KHS: Lesons Learned from the implememntations
LGR: I think the Mobile and Cognitive Task Forces will be starting to explore some of this. Greggs hybrid will bring this in as well. We are going to have to go back and rethink things around the UI
JF: almost me too. David when you talk about WCAG 3 - I freak out. I like theidea of WAI 2020. We like extension specs.
... It s about messaging and branding. If we start thinking about drastic name changes - we need to be really really mindful. WAI 2020 can be the umbrella.
... It is not that difference, It is an extension
JB: I will relay to Jeff that WAI 2020 is being well taken here. If we sell it as a package - this name is a placeholder for a really good discussion. We hope that poeple understand that this is place that is welcoming place (at the W3C) to have this discussion.
... Our door is open. WCAG 1 got alot of feedback. WCAG 2 WAI asked the WCAG WG as a convergence standard welcoming perspective from peopleall around he world
JN: Some of the things that Gregg was talkingabout is really freaking me out. I was thinking we are using ARIA to give everybody the same accessibe UI
LS: That is important. Web of Things - broaden it, ICT is more than the web. We need to look at these ICT UI for everything. (Our heating system)
JO: I like JOhn's idea, do not break what we have
LS: The other advantage of WAI 2020 instead of WCAG-2020 - this will annoy companies.
DM: Strike the WCAG 3
GV: New-AG sound nice. WAI 2020 can be more than GL. It is not promising a new WCAG. It is about a new WAI way. More global way (WAI)
... I hear people already saying wait to write your policy until after WCAG 3.
... Adam Osborn - Osborn 1 a portable computer, Do not bring out a hope for something else. WAI 2020 really is the right name/vision. The reason you are putting in WAI ARIA in is so that you are putting in this information that is available for others to use
... For cognitive you cannot make one size fits all.
JN: We have these modes where we render a different UI but we are now removing those because of all of the issues
GV: These are the important issues that we need to raise
<Zakim> AWK_, you wanted to pose the question "who are the key stakeholders that we need to have discussions about implementation experience with?"
AWK: Should be generate a list of the key stakeholdeers who we want to hear from are?
... Canada, New Zealand, Austalia andsay tool vendors?
GV: What about web seminars, like TED talks - give half hour webinars and capture them - they can be people just sharing different thoguht - and those people can recommend others.
... You could have a place where people could suggest other people to bring into the discussion
... The IoT really makes you stop and think
TB: This is a paradigm shift
LS: With the WoT you are taking away functions that people used to have
<Zakim> Judy, you wanted to ask a really simple question on a detail
GV: : We have already done it - older people cannot send aletter as tey do not know how to send anemail
JB: Lets make it WAI 2020
<MichaelC> W3C Workshop on the Web of Things, 25–26 June 2014, Berlin, Germany
<Judy> http://www.w3.org/2014/02/wot/
JB: that is a better hash tag. I will bealking about tomorrow ar tech tour, we scan community groups, workshops, there was a Web of Things workshop that is coming up. I hope they can amend their topic list
... We need
... We need folks to go there, we need the Ally talks there
JF: When can we start to talk about WAI 2020?
JB: Tell folks to join the WCAG WG.....frameit well...I iwll figure out some talking points
... I thought maybe in a few months we would have something
KHS: I want to do an intersection on Ally and Privacy talk
JB: Let meinteroduce you to Wendy Seltser
AWK: So we can think about this. But we are constrained about speaking about this. We need for clarity on timing. Maybe we want it after the NMPRM.
JB: The concrete question what kind of discussions, events, etc would be useful to collect during the coming year?
... What is the advise on how to frame that? Maybe the talking point is"what are your thoughts on how to frame this discussion"?
... The actionable step is that WAI begins to commit to those discussions
AWK: Is WAI 2020 a noun or a verb?
JB: It is being built. If you choose to accept this task. For instabce in Nov in China - can you have a ninput for future ideas in Beiging? Yes
DM: AmI right in saying that WCAG 2.2 or 3 is off the table
GV: WAI 2020 is a dicsussion about the where the WAI wants to position itself for how to address technology in 2020
JO: We all are aware that technology is quickly changing, so WAI 2020 is a fresh though.
JB: Does this work for people oris this awkward?
DM: I through out WCAG 3 and it was not a good idea.
JF: If we have this we are not going to mess with WCAG 2.
JB: The cogniitve stuff cant wait for 5 years
KHS: Look towards WAI 2020 - but let it be know that until then the NON Normative documents and techniques will be addressing the changing technologies now
JO: Get Cognitive andMobile TFs going and the Techiques and the nthe WAI 2020 doscussion can be going on
AWK: Yes, so weneed to define how to do that Tandem work
LGR: I think getting the feedback on WCAG 2 implementations will help us on what to do moving forward
GV: If we take it to the higher plane - I do not want to have patching WCAG 2
AWK: Who would like to create a proposal to do that?
GV: I will
JO: I will
<AWK_> Also Kathy W
<Judy> JB also interested
GV: We have some people into talk for you. I will pull clips from State Of the Science talks and I will send it to you.
JB: There will be all kinds of discussions coming from different places
AWK: I just want WCAGs view to take acrack at WCAGs veiw
?me Dinner at 7
<jamesn> scribeNick:jamesn
<MichaelC> Source Format Reformatting issue collection
<MichaelC> Source Format Reformatting issue collection
AWK: talking about improving public input and source format
MC: have put a URI into IRC with a wiki where collecting info about this
... we have already mocved our sources to github and are starting to explore how to take input via github
... nive thing is that public can make an edit BUT they have to edit xml sources
... that might have been the tippoing point. Now at the chair level thinking about revising the source format
... has been using XMLSpec which has a bunch of structural features. but wcag is different and techniques have which are highly crosslinked and copied so it is a bit different there
... a lot of mixing of content. solves a lot of problems but increasingly unwieldy
... getting harder to fix bugs
... so in the wiki page have started listing problems with current format
... we might want to create a new format
... started to create requirements. This list is not complete
https://www.w3.org/WAI/GL/wiki/Source_Format_Refactoring#Requirements_for_new_format
open for discussion how much we want to enforce validation
MC: a bunch of errors caused by duplication so wantt o avoid that
... the a11y support db poeople depend on test procedures of technqieus so they need to know about upgrades
... hard now as the xml files are in massive files. Hard to tell what is changed
... change histories
... manual diff markup - we provide a diff-marked version. Every one of those diff markings is manually maintained
... revision control systems have this info so need to autromate this
... output various forms of docs. need to be able to still do this
JF: no epub?
MC: can add that requirement
... also need to make it easy for WG members to edit
... we don't want unvetted edits so good iin a way
... need to seperate proposed from approved edits
... github helps with this
... also make easy for public to suggest edits
... including whole techniques
EH: is commenting allowed?
MC: that could be something we could add
AK: the [ull request allows a description
MC: but that gets lost when gets integrated
... do we want people to be have to use github
... technical considerations
... Should we use an XML format (optionally that uses a lot of HTML in it), or should we use vanilla HTML with special markup (sections, ids, classes) to enforce structure?
... HTML has WYSYWIG tools but could be hard to enforce structure
... a 2nd question is do we use an XSLT-based generator or would we use a script-based generator
AWK: 1 file for aria technqiues but gets used in a bunch of documents
MC: you would not want to do it by habd
... i am more comfortable with xslt than script but not sure that is a requirement
... we expect to continue with git but not a given
... https://www.w3.org/WAI/GL/wiki/Source_Format_Refactoring#Work_plan
Collect and prioritize requirementsDevelop a proposed format that appears to meet the requirements.
Transform the existing materials into the proposed formats, in a testing branch.
Develop the generator that outputs the desired final materials.
Test the generator's output. Revise the format as needed, and revisit requirements if needed.
Approve the format and generator output.
MC: do we want to embark on this - will cost a lot of my tiume
... and if we are going to embark on it we need to get a com[plete set of requirments
... there was an attempto to design - but requriements change
LGR: sounds like it leaves us in a more maintainable state
MC: we talked about new work. and new technique development
AWK: we have had interest from govt of canada to create techniques for example
... need a pathway to get help
+1
LGR: what else would you be doing if not this
AWK: this is an upfront investment with immediate payback. There is a lot of effort whcih is not really necessary
GV: how much work would it save on each publication?
MC: it is the developing the materials where it saves time and increases quality
AWK: also about allowing people to follow through and cfreate technqieus
MC: <outlines current tortuous path of creating techniques>
GV: I'm not sure that the 2 times you copy over are going to save any time.
MC: only pull requests on a branch - but if we want to accept their input then we would still have work to do.
<AWK> Sample of XML structure: https://www.w3.org/WAI/GL/wiki/index.php?title=SourceSample&action=edit
AWK: learning curve to what makes sense
... some things like doing a link is a LOC not an A
GV: they could be contributing general techqniesu without knowing html
MC: could create a structure and then they could use a wysywig editor
... ensuring we get the right format is harder
... more about omitting a class or putting them in the wrong order etc
AWK: even the current format - a simple form which might be limited could drive info into the correct structures
MC: the current form tries to do that but the xml it generates is not in sync with what we now use
... i've been in charge of this since ben left - at first didnt want to mess with it but i havne;t up till now.
... have been thinnknig about for years
AWK: it is just to shut me up
MC: Andrew was the canary for non wg members to commit content
... this could become a priority
... would slow down some of the support to indieui and aria1.1
... would slow me down on participation on technique development
... would be doing less participation in the technical work
ryladog: we had a license to xmlspy before which helped with the xml. What format would be easiest to get additional help
... we shouldn't be using comething archaic
MC: neither are archaic. When it was all set up it scripting wasn't viable but now it is
... would be HTML5 if we go with HTML-based solution
... HTML vs XML and script vs XSLT are different discussions.
AWK: if using git then it is important that folks can see the html version of the outpur within moments of creating the xml doc
MC: that does require script as the solution
AWK: don't think is does.... to be able to so a server-side xslt generation and then view that
MC: need to find which are importaqnt and which are not met by the current sources
... many of the current requirements are not met by the current sources
ryladog: if and when 508 refresh happens and we are pointing to the techniques. Would we want this done and in place before that
MC: requirement is that the generated docs are still at the same URIs
... going to html requires that it is importtant that the public can edit sttuff
... and deprioritises things like enforced structure
... lots of easy mistakes can be made with the current format
... there is no good reason for some of the things like LOC instead of A
... that would be easy relativey speaking
... question there if it is worth the investment
... if i make modest changes to the source format then the amount of work on the generator is reasonably high and the payoff is low
AWK: how firm do you think these requrieoments are
MC: could use some eyes - also probably missing some. Also no prioritisation of these
DMD: we are making a good change to github - now stabilise that and maybe revisit that
MC: already runnngin into difficulties due to reasoins like source files so biug
LGR: i can't see ntyuhing leaping out in terms of priorities but i'm not the one running into these issues
MC: i am not convinced myself. I lean towards wanting to refactor
... every time i do a pub i have hair pulling and every time i get through it and am thankful when it is over. Then next time there is another issue etc. The amount of time ovetr the years has grown to be significant
ryladog: i am under assumption that we are going to be doing technique releaseds more often
AWK: every 6 months is target
MC: i would like to do it
... quick fix to switch to individual files per technique
... I think it would take 3 months
<AWK> MC: there may be some things we could do easily and then do other things later
<AWK> LGR: sounds like long-term maintenance that actually pays off but there are short term unknowns
<AWK> SAZ: Translators have had issues also
<AWK> MC: Refactoring should help that also
<AWK> LS: worries about MC time on PF and other groups
<AWK> MC: Would have to support these less for a time period
<AWK> MC: if we're changing public input process then we might be suggesting that people use the new format
<AWK> MC: If we don't refactor then people will develop techniques in wiki
<AWK> MC: one compelling reason is to increase public participation
<AWK> SCribe: AWK
<scribe> Scribe: AWK
MC: If public input is a high requirement then the W should be involved as beta testers
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/bu June/by June/ Succeeded: s/taht/that/ Succeeded: s/greb/Gregg/ Succeeded: s/FAW/FAQ/ Succeeded: s/an umber of/a number of/ Succeeded: s/accessibiliyt/accessibility/ Succeeded: s/teh/the/ Succeeded: s/this is black based/this is blessed based/ Succeeded: s/lat/last/ Succeeded: s/lat/last/ Succeeded: s/Cognt/Cognit/ Succeeded: s/mentr/metri/ Succeeded: s/TG/TF/ Succeeded: s/tni/thi/ Succeeded: s/rece/rce/ Succeeded: s/inthere/in there/G Succeeded: s/inthe/in the/ Succeeded: s/anditerativechanges/and iterative changes/G Succeeded: s/al lkinds/all kinds/ Succeeded: s/onthis/on this/ Succeeded: s/WAI2020/WAI 2020/G Succeeded: s/WAI 2020/WAI 2020/ Succeeded: s/thinktheMobile/think the Mobile/g Succeeded: s/WAI-2020/WAI 2020/ Succeeded: s/WAI 2020/WAI 2020/G Succeeded: s/WAI 2020/WAI 2020/G Succeeded: s/WAI-2020/WAI 2020/ Succeeded: s/WAI-2020/WAI 2020/G Found Scribe: JF Inferring ScribeNick: JF Found Scribe: Loretta Inferring ScribeNick: Loretta Found Scribe: Kathy WARNING: "Scribe: Kathy" command found, but no lines found matching "<Kathy> . . . " Continuing with ScribeNick: <Loretta> Use "ScribeNick: dbooth" (for example) to specify the scribe's IRC nickname. Found Scribe: Katie Haritos-Shea Found ScribeNick: Ryladog Found ScribeNick: Ryladog_ Found ScribeNick: jamesn Found Scribe: AWK Inferring ScribeNick: AWK Found Scribe: AWK Inferring ScribeNick: AWK Scribes: JF, Loretta, Kathy, Katie Haritos-Shea, AWK ScribeNicks: JF, Loretta, Ryladog, Ryladog_, jamesn, AWK Default Present: Marc_Johlic Present: Andrew_Kirpatrick James_Nurthen Lisa_Seeman Shadi_Abou-Zahra David_MacDonald Kathy_Wahlbin Eric_Velleman Klaus_Miesenberger Paul_Adam Tim_Boland Loretta_Guarino_Reid Joshue_O_Connor John_Foliot Katie_Haritos-Shea Mary_Jo_Mueller Gregg_Vanderheiden Loretta_G-Reid Andrew_Kirkpatrick Josh O'Connor Michael_Cooper Josh_O'Connor Tim Boland Kathy Wahlbin Judy_Brewer Marc_Johlic Wilhelm Agenda: http://www.w3.org/WAI/GL/2014/03/ftf-meeting Found Date: 18 Mar 2014 Guessing minutes URL: http://www.w3.org/2014/03/18-wai-wcag-minutes.html People with action items: group josh joshue shadi wcag wg working WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]