Minutes: Low Vision Task Force 6 Dec 2018

 https://www.w3.org/2018/12/06-lvtf-minutes.html

Attendees
PresentJason, Jim, Laura, Shawn, jon_avilaRegretsChairjimScribeshawn,
jon_avila
Contents

   - Topics <https://www.w3.org/2018/12/06-lvtf-minutes.html#agenda>
      1. overview <https://www.w3.org/2018/12/06-lvtf-minutes.html#item01>
      2. Gap Analysis/User Requirements- Review 2.1 SCs
      http://w3c.github.io/low-vision-a11y-tf/user-needs-coverage.html
      <https://www.w3.org/2018/12/06-lvtf-minutes.html#item02>
      3. Non-Text Contrast Updates https://github.com/w3c/wcag/pull/550
      <https://www.w3.org/2018/12/06-lvtf-minutes.html#item03>
   - Summary of Action Items
   <https://www.w3.org/2018/12/06-lvtf-minutes.html#ActionSummary>
   - Summary of Resolutions
   <https://www.w3.org/2018/12/06-lvtf-minutes.html#ResolutionSummary>

------------------------------

<shawn> scribe: shawn
overview

wanting people with knowledge/interest in low vision & Personalization to
contribute
Gap Analysis/User Requirements- Review 2.1 SCs
http://w3c.github.io/low-vision-a11y-tf/user-needs-coverage.html

[ Jim goes over Gap Analysis/User Requirements ]

Jim: all have edit access. please review and add info

<jon_avila> Could you share that link again Jim. Thanks

http://w3c.github.io/low-vision-a11y-tf/user-needs-coverage.html

<jon_avila>
https://github.com/w3c/low-vision-a11y-tf/blob/gh-pages/user-needs-coverage.html

Jason: Working on large mouse cursor and issues.

<AllanJ> jim: annoyance with portrait monitor and web pages not fitting in
width of monitor. must scroll left/right

Jason: issues with tooltips

JonA: got some into WCAG 2.1

JimA: [background on SC] ... had to put in exception for browser exception.

Laura: Lots of stuff on our wiki. Pushed it to Silver.

Jason: anyithing about visual affordance?

JonA?: suggest add as a user need

<jon_avila> JonA: would like to add in user need for visual affordances.

<jon_avila> scribe: jon_avila

jonA: while related to contrast visual affordance go beyond. In order to
know if something is actionable user must move keyboard focus or mouse.
... User affordance of interactive elements

<AllanJ> jon: perhaps add visual affordance as a User need. it is related
to contrast. Lots of information in focus or mouse hover to tell user what
can happen

<shawn> jonA: example - peice of text is actionable but nothing incating it
is actionable

Jona: Example would be text with no other indicator. If you focus it or
hover then suddenly you know it's interactive.

<AllanJ> jonA: focus vs non-focus contrast is an issue

AllanJ: maybe visual affordance contrast might be whole other SC. We
started thinking about charts and graphs and then all focus ring and hover
indicator form controls and affordances got sucked into that and muddied
water. Pulling out as separate thing so non-text could go back. They were
originally separate.

Laura: It went back and forth and ended up together.

Shawn: motivation to combine was to limit number of new things.

<AllanJ> originally, 1.4.11 was 2 separate SC 1 for charts and graphs, and
1 for visual affordance.

Laura: Makes it more complex.

AllanJ: Please throw you 2 cents worth into github document so we can send
off to AG so they can use it for planning in 2.2
... Some aren't user needs be cause we don't have that yet. Have a lot of
information on our wiki and originally proposed SCs.

JGrieves: Does this cover consistent dark or light theme applied to system
that applies to content areas as well?

allanJ: User needs to be able to change it however they want it -- such as
examples from Wayne who has a low contrast interface.
... That's what the user need. Different from guideline that restricts to a
particular.

JGrieves: often hear need for boldness - may not be contrast. Just a darker
screen.

<AllanJ> jonA: there is a need for users to have granular control of colors
for high contrast
Non-Text Contrast Updates https://github.com/w3c/wcag/pull/550

AllanJ: Jump to item 4 which covers a lot of item 2. these are proposed
changes from Alasatir has put together for understanding updates for SC for
non-text onctrast. 1.4.11
... Seeking feedback in comments or in email. Discussion on WebAIM related
as well.
... On github page and AG WAI list. Components must continue to have
contrast in different states required to identify the state.
... Gave an example of checkbox. You need to be able to identify checkbox.
It's not so much the functionality but the indicator that has to have the
contrast to see it.

<AllanJ> jonA: example of button that slighly darkens on focus or hover,
the color change is too subtle, should be at least 3:1

<AllanJ> ... what is definition of adjacent... all adjacent colors or just
1 adjacent color.

<AllanJ> jim: there is a large thread about combinitorics.

<AllanJ> jonA: need techiques

<AllanJ> @@ a strong need for definition of adjacent.

<AllanJ> jonA: does the border change the shape "enough" to not need color.

allaj: what is enough for the change. Is it a 3 pixel change all around?

<AllanJ> list of indicators of visual indicators of focus

<AllanJ> -- color

<AllanJ> -- width

<AllanJ> -- shape change

<AllanJ> -- bold, underline or other attribute

<AllanJ> -- border change

<AllanJ> -- motion (when you miss type password and the text shakes)

<AllanJ> -- color fade (or control fade - webaim, skip link)

<AllanJ> -- change needs to be persistent during the state (if a focus ring
appears on focus it stays while focus is active ... doesn't fade away)

<AllanJ> -- -- keyboard focus disappears when you move the mouse, both
should be persistent

<AllanJ> jonA: perhaps persistance (user option) is a Silver item

<AllanJ> in issue 550 ...

AllanJ: Alastair has list of things that are not in scope.

<AllanJ> Not in scope:

<AllanJ> -- Boundaries for links / buttons.

<AllanJ> -- Default (untouched) focus indicators.

<AllanJ> -- Measurement is against adjacent colors of the component, not
different states within the component (except when color-change-only is
used for focus state).

<AllanJ> -- Hover / visited state (except that the component must continue
to have contrast). Whilst desirable that a component would indicate hover
state in a perceivable way, it is not required by 1.4.11.

allanj: browser default highlight for listbox is often non-conformant. Some
browsers like Edge do it well.

<AllanJ> jonA: should be focus and selected state (except when
color-change-only is used for focus state).

AllanJ: Most browser don't allow the selection state of listbox to be
adjusted.

<AllanJ> Jim: what is a "boundary"

<AllanJ> jonA: does boundaries for links and buttons mean you don't have to
add one?

Jim: Any other thoughts on hover contrast versus contrast of other states?
Not sure how we would attack in 2.2

JonA: might be more of a silver thing.

<AllanJ> Agree that contrast between hover / visited state is out of scope

Laura: icon font proposal could use some plus 1s to move it forward

<laura> https://github.com/w3c/wcag/pull/531

<AllanJ> trackbot, end meeting
Summary of Action ItemsSummary of Resolutions[End of minutes]

On Wed, Dec 5, 2018 at 9:20 AM Jim Allan <jimallan@tsbvi.edu> wrote:

> Time: 11:00 am Eastern Time (GMT-04:00)
> IRC: irc.w3.org:6665/  #lvtf
> Teleconference connection info (requires W3C login permission):
> https://www.w3.org/2017/08/01-lvtf-info.html
>
> Agenda+ Gap Analysis/User Requirements- Review 2.1 SCs
> http://w3c.github.io/low-vision-a11y-tf/user-needs-coverage.html
>
> Agenda+ Low Vision Survey Results
> https://webaim.org/projects/lowvisionsurvey2/
>
>
>
> --
> Jim Allan, Accessibility Coordinator
> Texas School for the Blind and Visually Impaired
> 1100 W. 45th St., Austin, Texas 78756
> voice 512.206.9315    fax: 512.206.9452 http://www.tsbvi.edu/
> "We shape our tools and thereafter our tools shape us." McLuhan, 1964
>


-- 
Jim Allan, Accessibility Coordinator
Texas School for the Blind and Visually Impaired
1100 W. 45th St., Austin, Texas 78756
voice 512.206.9315    fax: 512.206.9452 http://www.tsbvi.edu/
"We shape our tools and thereafter our tools shape us." McLuhan, 1964