Low Vision Accessibility Task Force Teleconference -- 14 Jul 2016

<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