See also: IRC log
<trackbot> Date: 13 May 2014
<Loretta> brb
<AWK> Scribe list: https://www.w3.org/WAI/GL/wiki/Scribe_List
<AWK> Scribe: Bruce
Lisa address group for update.
Mix of folks from CSUN face-to-face
Something could go to ARIA, to CAPTCH paper, WCAG WG
Mandated for work on gap analysis and word map and technques
Gap analysis first and important focus since eight different disability groups have been identified.
Not just AT compatibility, but feature needs
GPII has some similar work
<Lisa_Seeman> https://www.w3.org/WAI/PF/cognitive-a11y-tf/wiki/Main_Page
Work is in public, actively trying to avoid copy right issues
<Lisa_Seeman> https://www.w3.org/WAI/PF/cognitive-a11y-tf/wiki/Gap_Analysis
As with other wiki, work in progress, not authoritative necessarily
<Lisa_Seeman> https://www.w3.org/WAI/PF/cognitive-a11y-tf/wiki/Section_3
<Lisa_Seeman> good practices and avoid bad practices
<Lisa_Seeman> https://www.w3.org/WAI/PF/cognitive-a11y-tf/wiki/Good_and_bad_practices
Staffing working to collect ideas that can help, good practices and avoid bad practices
includes inclusive design practices, can be outside WCAG techniques per se
<Joshue> +q to say that the more we can identify commonalities the better
cognitive load is a good example of common issue that people complain about
helps address different needs and different ATs
TextHelp and Arabic language support are also current examples
CAPTCHA coming up as an issue again, plan to make suggestions to PF on that
<Joshue> -q
Symbol space is also an area that needs more investigation, as symbols may be better for some people than languages
Some symbol sets have copyright issues
Copyrighted symbol set may be very much like native language for some people, but can't be shared across tools.
<Zakim> David, you wanted to ask for a short list of issues that people with cognitive disabilities complain about
Lisa: very early for generatizations
<Joshue> +q
short-term dependance on working memory issue for many different types of cognitive issues
Want to make interface to require as little learning as possible.
<jon_avila> Flat design is bad for people with low vision too IMO.
The “flat design” paradigm currently popular actually increases cognitive load.
It is better to have borders distinction between buttons for example.
Joshue thanks for feedback, and we are continuously looking for more overlap and suggestions.
AWK and Lisa invite participation with her task force.
WCAG members are already vetted, so volunteers needed!
Time-out issues also something that comes up frequently as barrier, easy to lose place and orientation.
Timeout likely to require re-checking.
(This relates back to David's earlier question.)
Reminder to check page, if your name is there, this is reminder.
Also need to add new items.
Also need volunteers to add your name.
Particularly, 2912, 2871
Main issues is that comments from working group tend to be bigger and need more work
<AWK> Suggesting new process for comments from WG members
<AWK> WG-raised issues should be filed in issue tracker http://www.w3.org/WAI/GL/track/issues/
<AWK> if raised on mailing list, migrate to tracker
<AWK> same for WG public comments, document they get moved to tracker instead of treated as public comment
<AWK> which resolves the public comment - by adding to tracker
<AWK> standing agenda item to walk through tracker issues and discuss
<AWK> people can put comments in issue or by email before WG discussion so dont need WBS
Working group suggestions tend to be deeper and more complex
Question to working group: How does this sound?
Question is if we should dialog less on list serve?
David is concerned that issues from public might no look like they are picked up.
David asks advantages for our tracker v git hub
AWK: we are figuring this out
WG has more familiarity with issue tracker than git hub
Michael outline process of tracker
Current issue is that formality of tracker works better for discreet issues
Concern with git hub is that it is not W3C controlled service
Would be alarming to loose git hub discussions
AWK: using tracker may seem a little redundant, but we know threads are preserved
<Joshue> +q
Joshue, any objections?
We are trying to reduce overhead, make things more efficient.
<MichaelC> My thoughts: we need a tracker for issues raised by WG members, so they don´t get lost. Suspect people use the public comments process for that, but that conflates issues and imposes extra formality that we don´t need.
<MichaelC> Using our tracker helps with assurance, so WG members don´t need to use the public comment process.
<MichaelC> Use internal tracker instead of GitHub issue management because we need a paper trail for posterity
<MichaelC> If GitHub goes down, we lose that
RESOLUTION: Adopt process as described for handling working group comments
Author of technique, Allister asking if he is on right track, asking for feedback
<Joshue> +q
Trying to get back to DOM plus text, but don’t want accessible version to look like it is dumbed down
Joshue thinks this may conflict with progressive enhancement
Loretta understand concern for alternate version, but since we allow them, this should fine technique for alternative version
<Joshue> +q
<scribe> Ongoing issue that documenting techniques is interpreted as advocating technique as best practices
Joshue concerns with perception versus what is actually proposed in practice
David tries to paraphrase
That the conforming alternative version is available by link.
<Joshue> +q
AWK paraphrases as page making extensive use of progressive design, but all states of DOM not all testible
So idea is to have explicit link to robustly tested version
Technique could be pragmatic response to having too many combinations to test.
David possible likes idea.
Don’t want this to be analogy of using back door kitchen door for wheelchair access.
Joshue likes approach since it can be quite practical. Great flag for bigger issues.
<Wilco> +q to include a warning
<Zakim> Wilco, you wanted to include a warning
Helps address versioning, and issues with accessibility supported.
Wilco: Could be good, may need significant caveats.
Would be better for default version to be accessible. Fallback options are always a concern.
<Joshue> +1
RESOLUTION: Communicate to Alistair that work is worth pursuing
Suggestion is get rid of acronym and just use abbr
Use abbr to mark up expansions
<AWK> https://www.w3.org/2006/02/lc-comments-tracker/35422/NOTE-WCAG20-TECHS-20130905/2854
Michael reviewing
RESOLUTION: Accepted as ammended
https://www.w3.org/2002/09/wbs/35422/13May2014/results#xcaptions
1. [Updated Technique] Combining adjacent image and text links for the same resource
AWK suggest getting rid of example with closing slash so example combined and simplier
Does not really seem necessary to have both XHTML and HTML.
Bruce asks why example are different.
Loretta points out that example have been there before, point was to rephrase as positive statements.
Bruce retracts his suggestion.
<AWK> http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H2.html
Edit may make DIFF hard to spot
Michael feels rewording is an improvement
AWK asks about combining two examples.
<Joshue> Agreed
Only difference is a single slash, too much text for such trivial difference.
David, Joshue, Bruce agree with simplification
Michael points out that HTML5 prefers HTML syntax!
RESOLUTION: Accepted as ammended
https://www.w3.org/2002/09/wbs/35422/13May2014/results#xaudiodes
Issue is that ARIA-invalid can be the solution or be part of a solution
Concern is that ARIA-invalid can be the solution or be part of a solution
Jon has concern with useability for folks with low vision
<Joshue> Changing the text may be sufficient?
Example uses border attribute, so that helps.
Jon has suggested edit with phrasing
<Joshue> +q
James likes having CSS techniques
David clarifies that with example icon is in CSS
<Joshue> +1 to Jons suggestion
Discussion to small modification to support using CSS
Jon's suggestion to second bullet, for example by using an error-icon rendered visually by some technique that does not rely on color such as a visual cue like a border.
James and others okay with this.
<MichaelC> ackme
Michael asked to clarify his comment.
Discussion that AT support may not be sufficient.
May want aria-invalid plus label technique
Discussion that objective is have discreet technique that does not rely upon lable
Concern expressed with statement: When visible text is used to programmatically identify a failed field and / or convey how the error can be corrected, setting aria-invalid to "true" is superfluous from a strict compliance standpoint.
Don’t want to steer people away from aria.
Michael: This harkens back to long standing concern AT-push issue.
We want to encourage support for aria, but not require it
Discussion of text edit...
Michaels comment also applies to example 2.
Discussion how to edit examples to keep them parallel in form.
<Joshue> brb
AKW and Michael make discussed changes to wiki page
AKW makes analogy to calendar controls
Highlight difference between “incorrect” and “missing”.
Examples now have both ARIA invalid and described by
<Joshue> +Q
Description updated as well.
<wilco> +q
Joshue asks about error correction versus just error identification
Wilco points out ambiguity in test procedure around “instructional text”
Discussion
<Joshue> BB: Isn't the requirement for the instruction text, we may not have prog association as an explicit requirement
Discussion that programmatic association for instructional text okay even if not required by SC, can be appropriate for technique.
RESOLUTION: Accepted as amended
Did not get to last couple items.
AWK: Have 5 or 6 techniques, but time running short
David has technique in progress for aria described by
Or may be aria labeled by, we can choose one over the other
Open call on Thursday, let Loretta or James know
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/IPII/GPII/ Succeeded: s/29.12/2912/ Succeeded: s/2.8.71/2871/ Succeeded: s/Comment from working/Main issues is that comments from working/ Succeeded: s/that issues might/that issues from public might/ Succeeded: s/Adopt proposal/Adopt process as described for handling working group comments/ Succeeded: s/is on right tracking/is on right track/ Succeeded: s/conflicts/conflict/ Succeeded: s/pursing/pursuing/ Succeeded: s/Wilco asks about/Joshue asks about/ No ScribeNick specified. Guessing ScribeNick: bbailey Found Scribe: Bruce Default Present: David_MacDonald, AWK, Bruce_Bailey, +31.30.239.aaaa, Wilco, kathleen, +1.571.389.aabb, jon_avila, Loretta, Lisa_Seeman, Michael_Cooper, Joshue, James_Nurthen Present: David_MacDonald AWK Bruce_Bailey +31.30.239.aaaa Wilco kathleen +1.571.389.aabb jon_avila Loretta Lisa_Seeman Michael_Cooper Joshue James_Nurthen Regrets: Kathy Agenda: http://lists.w3.org/Archives/Public/w3c-wai-gl/2014AprJun/0089.html Found Date: 13 May 2014 Guessing minutes URL: http://www.w3.org/2014/05/13-wai-wcag-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]