See also: IRC log
<allanj> present?
<ScottM> JonA will be late
<shawn> scribe: Wayne
<shawn> https://github.com/w3c/low-vision-a11y-tf/issues/54
<shawn> http://www.w3.org/WAI/GL/low-vision-a11y-tf/track/actions/51
<shawn> e-mail thread: https://lists.w3.org/Archives/Public/public-low-vision-a11y-tf/2016Apr/0027.html
<shawn> +1 for commenting via GitHub (rather than separate e-mail) !
<allanj> Need: When the content author uses visual cues to guide the visual user’s
<allanj> scanning of the page, a user with reduced contrast sensitivity should be
<allanj> able to perceive the visual cues being used. Specifically, all such visual
<allanj> cues must provide sufficient contrast to support detection by users with
<allanj> reduced contrast sensitivity.
<allanj> Explanation: Often form fields and special blocks of text like definition
<allanj> or navigation sections are called out using borders or changes in
<allanj> background color. In these cases, the borders and altered background colors
<allanj> should provide sufficient contrast with the all adjacent regions of the
<allanj> page. This includes all borders used for form fields, radio buttons, check
<allanj> boxes and focus indicators. Objects that are distinguished by alternative
<allanj> colors including form fields should also have sufficient contrast as
<allanj> defined in the WCAG 2.0 glossary.
<ScottM> I am staying muted due to being in an open office, I'll comment here as needed.
<shawn> presnet+ Jeanne
jallen: Whatever our need is is to get out that non-text content meets that.
shawn: the user needs is that people can perceive background and border. Do we need to need to add a minimum contrast.
<ScottM> How about it applies to navigational elements
<ScottM> Guide lines, group borders, graphics that guide users to content etc
<allanj> wayne: tried to state as a user need. there is a lot of none text indicators on how to read a page. need enough contrast to perceive the indicators
<allanj> http://w3c.github.io/low-vision-a11y-tf/requirements.html#brightness-and-color
allenj: Most user needs are said "user can" but we may need a minimum contrast.
<ScottM> If I set high contrast mode in Windows and it removes all colors can I still see guide lines and other navigational graphics
AWK: What we hear in meetings is the color contrast, but I'm worried about enshrining a 4.5:1 number. Element level kind of does it.
Shawn: User need doesn't need a fix or a specific number (e.g., 4.5:1) - can be "sufficient"
<allanj> shawn: user can perceive all content, controls, reading indicators
<ScottM> We may need a higher contrast ratio as some graphics may be smaller than standard text or thinner
AWK: When we get to a success criterion that will work perhaps in different ways (element level customization).
<shawn> Action-51 Shawn will take another pass at it with input from telecon
<AWK> Scribe: AWK
<allanj> https://github.com/w3c/low-vision-a11y-tf/issues/59
Shawn: Will take Scott's comments into consideration in her next pass
JA: Password thing.
... people raised issues with PWs from COGA group and wondered
if it was a LV issue that the characters show up as stars or
bullets
<ScottM> It is difficult to count the number of stars, I can't always verify the letter before it changes
JA: any concerns?
<ScottM> To a star
<shawn> -- or is it sufficiently covered by our existing user needs ?
JR: Does this include CAPTCHA?
<ScottM> Captchas should be another issue
JA: No. That's separate
... but important
JR: There are alternatives to
pw's like biometrics, etc
... have issues as a person with low-vision
<ScottM> It is difficult to verify letters entered by counting stars, and it is hard to see letters before they change to stars
JR: Some fields don't let you paste into a field, which can be a problem
<ScottM> Yeah not being able to paste is also a pain
JR: Character discrimination is a pain point
<erich_manser> +1 hard to see letters before they change to stars
EM: Agrees with scott's
comments
... doesn't get much value from the temporary appearance of a
letter before it becomes a star in some systems
<ScottM> I don't know if it is relevant but there is a larger discussion about the validity of even masking characters for password fields
<JohnRochford> Correction: John knows, not thinks
<shawn> s/Correction: John knows, not thinks
WD: On some sites if you fail the
PW then you get bumped to a CAPTCHA
... that is awful
JA: Users don't have control over the appearance of the stars with CSS?
<ScottM> Password fields always use stars or some other masking character
SH: Users can change the text size, etc.
<ScottM> Password fields also prevent the user from copying data out of the field so you can't even copy and paste into a clear text area to verify contents
<ScottM> That is a mobile only feature
JR: Are we assuming that ppl know how to override fonts on pages?
SH: The user need is that ppl can
do it.
... the implementation question would be tied more to the
SC
JS: The stars (timing, etc) is a platform issue and authors won't have control
<ScottM> Correct Jeanne
<ScottM> Android will also allow users to demask some password fields but not in browsers
<ScottM> Masking characters should meet WCAG size and contrast requirements and there must be a 1 to 1 ratio of masking characters to password characters
<Zakim> AWK, you wanted to say that perhaps the user need is to turn the stars on/off is what is needed
<jeanne> +1 AWK :)
<shawn> AWK: NOT concerned about whether it's a pltform issue or not. [for these users needs] ... might inform what we do for WCAG.Next
<ScottM> This is what I was going to say for our response to password fields "Masking characters should meet WCAG size and contrast requirements and there must be a 1 to 1 ratio of masking characters to password characters"
<allanj> awk: the user need is to turn the stars on/off is what is needed, perhaps for WCAG next, include browser and authoring tools
<shawn> ... user need: way to see what password has been typed in (while also maintaining privacy)
<shawn> ... platform/UA concern
<allanj> ... user needs to be able to see password as they type it and maintain privacy
WD: agrees with JR on issue of user being able to readily accomplish the task
<allanj> scott - it is also a security need to mask the number of characters...hence lots of dots
WD: perhaps it mishandled in the success criteria, but it is a concern
<allanj> consequence of failure is high for passwords
JR: If you don't get a character right it is a problem for the user, which underscores the need for this to be easy
JA: If someone wants to do it, we need to figure out where in the doc to put it
SH: open issue in Github for that
<shawn> +1 for looking at the language the COGA has !
<allanj> awk: talk to coga, they may have something also have something we can piggy back upon
JR: Will "steal" the COGA SC on password viewing and see if it works for LV
<allanj> ACTION: JohnR to write "password" need [recorded in http://www.w3.org/2016/04/27-lvtf-minutes.html#action01]
<trackbot> Error finding 'JohnR'. You can review and register nicknames at <http://www.w3.org/WAI/GL/low-vision-a11y-tf/track/users>.
<allanj> ACTION: JohnRochford to write "password" need [recorded in http://www.w3.org/2016/04/27-lvtf-minutes.html#action02]
WD: very concerned about reliance on CAPTCHA
<trackbot> Created ACTION-52 - Write "password" need [on John Rochford - due 2016-05-04].
WD: a lot of the CAPTCHAs (and the audio versions) are very hard
<shawn> https://github.com/w3c/low-vision-a11y-tf/issues/30
SH: Jim made a suggestion about images to illustrate the concept
JA: We can do that and may be
able to close the issue
... Andrew Arch mentioned a style guide / pattern library for
Australia that has some challenges in it
<Wayne> + 1
<allanj> +1
<shawn> +1 for adding minor wording &/or images -- not a separate point
JA: OK, so we will add the images
<jeanne> +1
JA: How to move forward? We have
continual friction between user needs and need for specific
success critiera
... perhaps we split up the work a bit?
<allanj> https://github.com/w3c/low-vision-a11y-tf/blob/gh-pages/WC-UA-alignment.html
JA: there is a table for the gap
analysis
... (see link above)
... table has user needs for LV and another column for mapping
to WCAG and UAAG and ATAG and we will use to find the
gaps
... also a column for "coverage"
... some LV requirements map incompletely and that is where
notes on the specifics go
... the more we can fine-tune the changes the easier our
progress will be
... maybe we do half the meetings moving forward on finishing
the reqs doc and half on the gap analysis
... thoughts?
<jeanne> github version where you can read the table -> https://w3c.github.io/low-vision-a11y-tf/WC-UA-alignment.html
AWK thinks it is a good idea to get cracking on the gap analysis
<JohnRochford> +1
<allanj> +1
<shawn> +1
<jeanne> +1
AWK proposes a separate meeting where we can all go through the gap analysis line by line together for those who can
<Wayne> +1
<shawn> agrees it needs time
<allanj> +1
Jim will do a doodle poll for additional time to work on the gap analysis
<JohnRochford> Gotta go folks. Ciao
JA: Everyone should look at the gap analysis even if they can't make an additional meeting
+AWK
-1
-AWK
Trackbot, end meeting
This is scribe.perl Revision: 1.144 of Date: 2015/11/17 08:39:34 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/ Getting dialed in now// Succeeded: s/cures/cues/ Succeeded: s/need a fix./need a fix or a specific number (e.g., 4.5:1) - can be "sufficient"/ Succeeded: s/dofferent/different/ Succeeded: s/Are you guys seeing my comments?// Succeeded: s/Ok cool// Succeeded: s/* John thinks that LastPass often fails with automatic authentication// WARNING: Bad s/// command: s/Correction: John knows, not thinks Succeeded: s/Users can dictate the appearance of the temporary character appearance, but the star is the star/Users can change the text size, etc./ Succeeded: s/damask/demask/ Found Scribe: Wayne Inferring ScribeNick: Wayne Found Scribe: AWK Inferring ScribeNick: AWK Scribes: Wayne, AWK ScribeNicks: Wayne, AWK WARNING: Replacing list of attendees. Old list: allanj shawn JohnRochford Wayne ScottM Andrew(AWK) jeanne Erich 1 AWK jon_avila New list: allanj shawn JohnRochford Wayne ScottM Andrew(AWK) jeanne Erich jon_avila Default Present: allanj, shawn, JohnRochford, Wayne, ScottM, Andrew(AWK), jeanne, Erich, jon_avila WARNING: Replacing previous Present list. (Old list: (no, one)) Use 'Present+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Present+ allanj Present: allanj shawn JohnRochford Wayne ScottM Andrew(AWK) jeanne Erich jon_avila Regrets: Laura Found Date: 27 Apr 2016 Guessing minutes URL: http://www.w3.org/2016/04/27-lvtf-minutes.html People with action items: johnr johnrochford[End of scribe.perl diagnostic output]