See also: IRC log
<scribe> Scribe: erich
JA: need a schedule for when understanding docs will be complete
GS: if do not need written techniques, mine is done
LC: mine is pretty well done too (adapting text)
<allanj> jim put UI contrast and Adapting Text Understanding doc on Agenda for next week
<allanj> jim put a note out to group for getting on agenda.
<allanj> https://github.com/w3c/wcag21/issues/350#issuecomment-327589159
SR: would like to discuss some of the last-minute objections raised
<steverep> https://github.com/w3c/wcag21/issues/75#issuecomment-321443487
SR: Issue about repositioning may
be easier to resolve than issue with trigger
... repositioning was added based on an objection
<allanj> current SC
<allanj> When a user interface component which receives keyboard focus or pointer hover causes content to become visible, the following are true:
<allanj> Visible Trigger
<allanj> Either the additional content does not obscure any essential content within the triggering user interface component, or the additional content can be closed or repositioned by the user;
<allanj> Hover
<allanj> If the additional content is triggered via pointer hover, then that content remains visible when the pointer is moved over it;
<allanj> Focus
<allanj> The additional content remains visible while the triggering user interface component has keyboard focus, unless the user dismisses the additional content.
<allanj> Exception: The visual presentation of the content is controlled by the user agent and is not modified by the author.
GS; feel kind of neutral. the way I read it, if the trigger is obscured, but you can reposition, it's ok but not ideal
SR: I propose language that, if you can reposition off of the trigger itself, then it makes sense
GS: I would agree with that
<allanj> repositioning is big loophole
SR: moving windows around is generally not something low-vision folks do
<allanj> would there even be a repositioning technique
<allanj> repositioning seems to be under user control
SR: you don't necessarily need a techniqure for it, but regardless, if you think about the sharepoint example you would just need different on-hover regions for the same object
JA: what should we support you on Steve?
SR: I am going to file an issue,
which hopefully will be discussed and we can take care of
it
... would like to get it resolved through language that
everyone is okay with
... I am proposing language that explicitly says it can be
repositioned off of the trigger
... support could come in the form of comments on the issue I
feel, or specific resolutions we have here about what is or
isn't okay in terms of low-vision
JA: Steve could you bring this back next week, to allow time for review, discussion and identification of proper resolutions?
SR: Sure, sounds good.
<allanj> jim put Hover on agenda for next week. discuss on list https://github.com/w3c/wcag21/issues/75#issuecomment-321443487
GS: we have logical reasons for
saying 4.5:1 for things that are thin, but the complexity of
testing for that may not be worth it
... if we just get 3:1, it is reasonable to ask people to test
for
... majority of research leading to 4.5:1 was based on
reading
<allanj> https://github.com/w3c/wcag21/issues/345
GS: color contrast need are not specific to reading, are more complex
JA: a frequent issue i've had is with form controls, even at 3:1 at times
GS: could we get examples of
insufficient contrast at 3:1?
... major concern is if we fall too quickly back to 3:1 we
could shoot ourselves in the foot
... no need to exclude any possibility of using 4.5:1 for
certain thinner elements
<allanj> research this
<allanj> more than a survey, need demographics. someone who understands low vision
<steverep> Do we have a link to his talk?
<allanj> Erich: Howard Kaplan, low vision reading, invite to a call
<Glenda> Research I found interesting:
<Glenda> http://www.vectorvision.com/contrast-sensitivity-background/
<Glenda> http://www.vectorvision.com/csv1000-norms/
<allanj> contrast vs acuity limit
<Glenda> Here is the talk that Jared did on Rethinking Color and Contrast https://www.youtube.com/watch?v=HtUlonNewGk&index=1&list=FLio9ud-Ay0NKxGlcUZLhQVQ
<allanj> with poor contrast single pixel line width fonts vanish
SR: many people also have glare sensitive, photophobic considerations
<allanj> total luminance is an issue for reading
<Glenda> The importance of Contrast Sensitivity https://www.youtube.com/watch?v=HtUlonNewGk&index=1&list=FLio9ud-Ay0NKxGlcUZLhQVQ
<Glenda> “Contrast Sensitivity Function (CSF)
<Glenda> Detailed contrast sensitivity measurements that include both size (spatial frequency) and contrast are used to plot a person's contrast sensitivity function (CSF).
<Glenda> Sine-wave grating targets with thicker bars represent low spatial frequencies; targets with thinner bars represent higher spatial frequencies. In this regard, determining a person's CSF is much like evaluating the sensitivity of his or her hearing, which involves using tones of low and high pitch as well as variations in volume.
<Glenda> Your contrast sensitivity function essentially is a plotting of the curve that defines the lowest contrast level that you can detect for each spatial frequency tested.
<Glenda> Generally, objects with high spatial frequencies (sine-wave gratings with very thin bars) must have significantly higher contrast than objects with lower spatial frequencies (gratings with medium-width bars) to be detected by the human visual system.”
<shawn> ACTION: Shawn consider in user needs/req issue with overall luminance (e.g., light background) SR's point in 14 Sept 2017 [recorded in http://www.w3.org/2017/09/14-lvtf-minutes.html#action01]
<trackbot> Created ACTION-102 - Consider in user needs/req issue with overall luminance (e.g., light background) sr's point in 14 sept 2017 [on Shawn Henry - due 2017-09-21].
SH: Steve has a good point, we need to have reflected in our user needs document
<Glenda> http://www.precision-vision.com/?s=contrast%20patti Look at this
<allanj> this is low contrast vs acuity limit test not with letters
<Glenda> http://www.vectorvision.com/csv1000-contrast-sensitivity/
<Glenda> Standardized Contrast Sensitivity Tests
<allanj> "open" captions is editorial
<allanj> discussing https://lists.w3.org/Archives/Public/w3c-wai-gl/2017JulSep/1001.html
<laura> 5. text color to any color that the user agent allows
<laura> 6. background color to any color that the user agent allows
<laura> 7. font-family to any font family that the user agent allows and has immediately available
<laura> NOTE: If the user is changes the text and background colors - then the author is not responsible for meeting any contrast SC other than for the colors specified as default by the author.
<allanj> lots of push -back on Fonts
<allanj> color/contrast alastair comment https://github.com/w3c/wcag21/issues/348#issuecomment-329119866
<allanj> The one that comes up (occasionally) is background images. E.g. you have a solid (or gradient) blue background with white text. The user changes the text colour to blue, and can't read it.
SR: should focus on few things that can go wrong with color
<allanj> transparency
<allanj> it seems the group thinks these are a non-issue
<allanj> jim will revisit greg 3 bullets next week for resolution.
<laura> https://github.com/w3c/wcag21/issues/349
<steverep> What comment are we dicsussing?
<allanj> The one that comes up (occasionally) is background images. E.g. you have a solid (or gradient) blue background with white text. The user changes the text colour to blue, and can't read it.
<laura> https://github.com/w3c/wcag21/issues/78#issuecomment-323662527
<allanj> PDF fails the sc. but works in browsers
<allanj> if you provide an alternative conforming version you are done
<allanj> -- shawn
<laura> Andrew’s email: https://lists.w3.org/Archives/Public/w3c-wai-gl/2017JulSep/1009.html
<allanj> seems that PDF can't be reliably tested. would hate to restrict the SC, so when PDF can meets the SC then it can be tested
<allanj> SR: the exception seems to cover PDF
<allanj> user agent goes back to technology support.
<allanj> because a browser doesn't read alt text to the user, the page does not fail WCAG
<allanj> because pdf reader cannot display arabic font, the page doesn't fail the SC
<shawn> if new technologies come up that don't support alt text, that doens't mean it doesn't meet WCAG
<allanj> concept - accessibility support, conformance in general. supported by user agents, widely available.
<allanj> a new user agent that is not accessibility supported is not a worry.
<allanj> perhaps in the understanding document we say PDF user agent does not allow these changes and so is untestable
<laura> bye
This is scribe.perl Revision: 1.152 of Date: 2017/02/06 11:04:15 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/"open/"open" captions is editorial/ Succeeded: s/revist/revisit/ Present: Jim Glenda Shawn steverep Erich Laura WARNING: Replacing previous Regrets list. (Old list: JohnR) Use 'Regrets+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Regrets+ John Regrets: John Found Scribe: erich Inferring ScribeNick: erich Found Date: 14 Sep 2017 Guessing minutes URL: http://www.w3.org/2017/09/14-lvtf-minutes.html People with action items: shawn WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]