Minutes: Low Vision Task Force July 14, 2016

Hello everyone,

Minutes from today's teleconference can be accessed as hypertext at:
https://www.w3.org/2016/07/14-lvtf-minutes.html
and as plain text following this announcement --  please report any
errors, omissions, clarifications, mis-attributions, and the like by
replying-to this announcement on-list...

Thanks.

Kindest Regards,
Laura
- DRAFT -
Low Vision Accessibility Task Force Teleconference
14 Jul 2016

See also: IRC log
Attendees

Present
    Laura, AWK
Regrets
Chair
    AWK
Scribe
    Laura

Contents

    Topics
        1100% https://github.com/w3c/low-vision-SC/issues/5
        Review: Techniques needed for Icon Fonts are there
implications for LV users?
    Summary of Action Items
    Summary of Resolutions

<AWK> +AWK

<AWK> +Wayne

<AWK> +ScottM

Scribe List: https://www.w3.org/WAI/GL/low-vision-a11y-tf/wiki/Scribe_List

<AWK> Ad hoc discussion of AAA-level items.

<AWK> Scott: thinks that people will freak out with 1100%

<Wayne> scribe, wayne

<scribe> Scribe: Laura

<ScottM> Thanks Laura
1100% https://github.com/w3c/low-vision-SC/issues/5

AWK: Scott thinks people will freak out at 1100%
... May push this into silver if we push to UA

Scott: has suggested language.

<AWK> From Scott's email: 5.Text can be resized without assistive
technology @@at least@@ 200 percent in a way that does not require the
user to scroll horizontally to read a line of text

Scott: Text can be resized without assistive technology @@at least@@
200 percent in a way that does not require the user to scroll
horizontally to read a line of text

<AWK> existing: 1.4.4 Resize text: Except for captions and images of
text, text can be resized without assistive technology up to 200
percent without loss of content or functionality. (Level AA)

AWK: people may only do the minimum requirement then.

Scott: just text resize can cause problems on and off the web.
... we have to look at seniors.
... they have hard time with a computer let alone AT
... We maybe should take a flexible approach.
... so people don’t lock in on values.

<AWK> AWK suggests: text can be resized without assistive technology
up to the magnification level supported by the user agent without
requiring horizontal scrolling.

Scott: will get push back on 1100.

<shawn> [ data point: quick check of default zoom maximums: Chrome
500%, FireFox 300%, IE 1000% ]

AWK: suggests “text can be resized without assistive technology up to
the magnification level supported by the user agent without requiring
horizontal scrolling.”

<AWK> Firefox can go above 300%

Wayne: until now, wasn't the opportunity to look at the full screen.
... we can fit more now with rewrap
... we have the opportunity to introduce a new technique.
... what we have now is not working.
... what we need is 10 to 15 char per screen.
... we know that we can linearize content.
... unless someone adds a barrier

<shawn> [ /me plays with bbc.com at 1000% magnification... impressive!]

AWK: what is the solution for the language.

Wayne: think of the page as a grid. At 10 and 15 em words don’t break.
... legge fond he could do 1000% on and ipad
... em unit is the most useful measure.
... page should be an em grid.
... linearized by block units and reflow is the key.

Scott: zoom text does this.
... all of the SCs need to work together.
... agree it would be awesome. But need to coordinate the SCs.

Wayne: if all the items on the page are linarized by block it will work.

Scott: problem is designers lock things down.
... do we make this part of a wider solution?
... if so how do we change the other SCs to coordinate them.
... we would need to rework 148 entirely.

AWK: Maybe not as this is under discussion.
... need to figure out at the WG level.
... don’t think we can use em units.
... does it work for every thing?

Shawn: yes, for any text there is an em width
... thinking about WCAG to ACT docs.

<Zakim> shawn, you wanted to suggest focus on ideal SC for now, then
synch with WCAG 2.1

Shawn: suggest focus on ideal SC for now, then synch with WCAG 2.1

<AWK> AWK: Sure

Wayne: one column, rewrapped, linearization are needed.

Scott: Design requirements may cause people to freak out.
... may affect fucntionality.
... can’t use em units.
... many people will not create their own style sheet.

<shawn> +1 for wrap / hyphenate

AWK: to wayne if you zoom in a lot, linearization would work and wrap.

Wayne: yes.
... would need to break word for 2.1. and hyphenation for silver.
... users wouldn’t be writing style sheets.
... an browser add-on would do it.
... it can be done.
... need a user profile.
... AT style sheets written by pros.
... we are talking about making base leve accessibility.
... 450% may be enough to get developers attention.

<Zakim> shawn, you wanted to say "blocks of text" so not forms, whole
tables, maps, game labels, etc. (and disagree that can't use ems
because users don't know them (although not

Shawn: We are talking about "blocks of text”.

<Zakim> AWK, you wanted to ask wayne if the browser add-on he describes is an AT

Shawn: it isnt a requirement that users know em units.

<Wayne> Users can resize text up to the uper limit of the user agent

AWK: Would like to see in silver. Text can be resized without
assistive technology up to the magnification level supported by the
user agent without requiring horizontal scrolling.
... flexibility is what we want to focus on.
... picking a number is problematic.

wayne: agrees with AWK.
... How do we do it. Does it go in silver?
... if pages were buit with progressive enhancement that would help.
... example of a barrier: Max set to 1 in the head.

AWK: If we go with ext can be resized without assistive technology up
to the magnification level supported by the user agent without
requiring horizontal scrolling. what are the repercussions?
... anything scanned wouldn’t pass.

<shawn> SLH: if XYZ UA only provides 150%?

Shawn: What is a browser only provides 150% zoom?

AWK: policy makers can put in exceptions for scanned docs.

Wayne: we need another SC for barriers for writing ATs

AWK: Don’t think we can.

<ScottM> If we do our job correctly we will reduce the need for AT

AWK: Should we work on this in Github?

wayne: yes.

<AWK> Wayne will work on detailing what the barriers are in creating a
browser extension for text enlargement and will add to the github
disussion

<AWK> AWK will add the magnification SC suggestion to the gitHub
discussion for comment
Review: Techniques needed for Icon Fonts are there implications for LV users?

<AWK> ACTION: Wayne to work on detailing what the barriers are in
creating a browser extension for text enlargement and will add to the
github disussion [recorded in
http://www.w3.org/2016/07/14-lvtf-minutes.html#action01]

<trackbot> Created ACTION-68 - Work on detailing what the barriers are
in creating a browser extension for text enlargement and will add to
the github disussion [on Wayne Dick - due 2016-07-21].

<ScottM> Ugh.....

scott: has have long dicussions on icon fonts. Scales well. But don’t
work well with screen reades and zoom text.
... becomes black boxes.
... am not a fan of them.

<Wayne> Actually not black boxes. They are boxes with the unicode
number inside. It takes lots of mag to see it.

scott: efficiency is rationale for using them.
... don't affect low vision specifically.

AWK: Do we need to have something that addresses this.

<AWK> Example to try: http://timepiece.inostudio.de

AWK: works in Screen readers.

<AWK> AWK: seems that much of the problem can be dealt with in WCAG
2.0 Techs and understanding documentation

<AWK> Laura made 4 techniques

<AWK> need review

.Using aria-hidden="true" on an icon font that AT should ignore

https://www.w3.org/WAI/GL/wiki/Using_aria-hidden%3Dtrue_on_an_icon_font_that_AT_should_ignore

Icon Font with an On-Screen Text Alternative

https://www.w3.org/WAI/GL/wiki/Icon_Font_with_an_On-Screen_Text_Alternative

Using aria-hidden="true" on Unicode characters that AT should ignore

https://www.w3.org/WAI/GL/wiki/Using_a_Decorative_Unicode_Character

Unicode Character with an On-Screen Text Alternative

https://www.w3.org/WAI/GL/wiki/Providing_an_On-Screen_Text_Alternative_for_an_Icon_Font

<AWK> email discussion:
https://lists.w3.org/Archives/Public/public-low-vision-a11y-tf/2016Jul/0035.html

<AWK> Key problem is that icons presented with icon fonts are
technically text but not regarded as such

<AWK> needs to be clarified moving forward

<AWK> Homework is to review Laura's documents

trackbot, end meeting
Summary of Action Items
[NEW] ACTION: Wayne to work on detailing what the barriers are in
creating a browser extension for text enlargement and will add to the
github disussion [recorded in
http://www.w3.org/2016/07/14-lvtf-minutes.html#action01]

-- 
Laura L. Carlson

Received on Thursday, 14 July 2016 16:42:59 UTC