LVTF Meeting Notes - Jan 19, 2017

Meeting minutes pasted below and at link:
http://www.w3.org/2017/01/19-lvtf-minutes.html


Low Vision Accessibility Task Force Teleconference
19 Jan 2017


See also: IRC log


Attendees
Present
      Jim, Shawn, erich, AlastairC, Laura, Marla, Wayne, AWK, Glenda,
      Joshue108
Regrets
Chair
      Jim
Scribe
      erich
Contents
      Topics
            User Adaptation SCs and "a mechanism is available" (Alistair)
            https://lists.w3.org/Archives/Public/public-low-vision-a11y-tf/2017Jan/0023.html

      Summary of Action Items
      Summary of Resolutions



<shawn>
https://mit.webex.com/mit/e.php?MTID=m7bd69a85ec402a9d06c38e4c4556ed3a



<shawn> meeting number 646 045 716


Scribe+ erich


User Adaptation SCs and "a mechanism is available" (Alistair)
https://lists.w3.org/Archives/Public/public-low-vision-a11y-tf/2017Jan/0023.html



AC: There was an assumption I want to call out
... If people override site styles, there are several categories that can
fit in
... I've tried to categorize them in to more- or less- disruptive
... Spacing and Font Family are becoming among more disruptive
... Example, selected font size can potentially break some layouts
... If linearization, spacing and font family we are assuming authors are
comletely overriding, that's another matter
... We need clarification, work out what the assumption is, and translate
from user requirement to a content requirement


<AWK> +AWK


<shawn> [ Shawn thinks about efforts to make the horizontal nav bar work
when people increased text a lot or had a small browser window in
https://www.w3.org/WAI/intro/people-use-web/ I wonder if that is helpful to
think about what uesrs need to do?]


AC: Linearize is on the end where author is completely overriding, Spacing
also tends toward complete override


WD: Alastair's summary helps
... May be a case of something like Resize Content


<Joshue108> +Joshue108


JA: To me, we always have issues around wanting large blocks of text vs.
text all over the place
... It still comes down to "What is it that you want authors to do?"


AC: In the case of Linearize, it's being written as if the user overrides
the layout, it's still usable
... Ex: scripts that use carousels use Javascript, when you try to
overwrite, it doesn't know the style sheet. There are techniques that need
to be written
... Spacing and Font Family I think are most difficult from this point of
view


<Zakim> AWK, you wanted to say that it may also come down to "what can
authors not do"


AWK: To add about what you want authors to do, we may also add "what do we
want authors to NOT do"
... Ex: authors if you are creating content, do not use XXX format


<shawn> AWK: if XYZ technology doesn't allow alt for images, then telling
authors that if you're creating content, then can't use that format


<shawn> [ Shawn - or at leat need an laternative version in another format]


AC: Question for AWK, the Resize Content is an interesting case, mobile
browsers don't do layout the same way as desktop browsers
... If we don't have an exemption, there's really nothing an author is able
to do to address


AWK: If we had a requirement that did not have that exception, 400% and
reflow, what would an author do to meet that on mobile


AC: Nothing an author could do


AWK: Well you can, may not be pretty but possible


AC: Point taken


AWK: This is a question we will be putting out, as to whether or not
tolerable


GS: Is considering as a AAA also an option?


AWK: yeah, we can


WD: I understand what AWK is saying, but I think that we would like to get
this in to the technology where it ca't be done, and establish normative
language


<Wayne> If no mechanism exists to change font family on any user agent for
the target technology, then the author is not responsible to create one.


WD: Much of what was missed is Level A


<shawn> [ /me not comfortable with Wayne's exception at this point ( but
might be talked into it)]


WD: I think that if we could get to in HTML5 CSS realm to make the changes
happen in the right way
... Creative programmers can do disastrous things very innocently


<Zakim> AWK, you wanted to say that I think giving such an exception to
less-accessibility-focused user agents is a mistake


AWK: I think that the strength of a SC is when we can say clearly that when
you do this, it helps the user.
... If we're saying users need to be able to increase the font size 400%
and not have the words wrap, we should say it


<shawn> +1 to not giving technology / user agent exception


<allanj> +1 to not giving technology / user agent exception


AWK: If not, they pull it out and don't have to support
... When we state it unambiguously, if puts pressure to make it happen


<alastairc> q


<allanj> Must meet the user's need.


SH: Wayne ok with not giving an exception?


WD; On first public working draft, I agree with Andrew


<Zakim> alastairc, you wanted to say that it seems remiss not to ask for
400% where it is (relatively) easy to do.


AC: I cannot see browsers making any changes in how they do layout, and I
not seeing a large scale need
... Would rather go in with 400% and an exception we might retire in 2.2,
then not get a good SC in to 2.


2.1 not 2.


LC: There is one user agent that does allow spacing in PDF


JA: VIP PDF viewer allows spacing


<laura> http://www.d.umn.edu/~lcarlson/wcagwg/spacing/comments.html#tech



JA: Acrobat Pro AC you can change those too, but at a cost


<Zakim> shawn, you wanted to comment on able to do X with this content - OK
can't do it on mobile, as long as can in desktop??? (Then maybe best not to
have excpetion, just explanation)


<allanj> PDF client VIP-PDF viewer does that


<laura> http://www.d.umn.edu/~lcarlson/wcagwg/spacing/comments.html#support



SH: On VIP Reader, it can only open certain types of files
... Definitely a case where it depends what the user does


<allanj> it also depends what the author does during the creation of the
PDF document


<laura> Shawn: VIP PDF Reader can adjust spacing.


WD: if you have completely compliant file, will it work?


SH: I will check. Not every file
... Issue with broad exception vs. specific exception, we need to be sure
we word that very carefully, so as not to make it more broad than intended
... Want to double-check, users with medium low-vision are not going to be
doing a lot of reading withmost mobile phones anyway. If content is
provided in HTML, which can be accessed via desktop browser, is it okay to
not have it not mobile accessible


AWK: I see a huge 'slippery slope' problem


<allanj> or a vr headset, or heads up display


<shawn> good point


AWK: We don't have data to say 'screens larger than xxx..." so we really
can't say


JO: we are limited out of the box as to what we can do, we can be in 'not
as bad' situation


<alastairc> The exception text for resize: "If the user-agent fits the
layout to the viewport and does not provide a means of reflowing content,
two dimensional scrolling is exempt."


AC: Worth bearing in mind that Zoom and Reflow work well on desktop is
because a mechanism was provided


<allanj> ... media query


AC: I do take the slippery slope argument to a certain extent
... Because there is a completely different way that authors approach
layout for desktop vs. mobile browsers


<allanj> [reflow works well for text and applications ... if you can use a
mobile view on a desktop screen]


<allanj> authors have control of that


WD: I did a calculation for a 4.7in cell phone screen, if you took print
and did a media query and stuck it on that screen, it would be .36 times of
a 13" screen
... net outcome running the numbers, it would be equivalent of enlarging
the laptop display to 500%
... asking for 400% on that phone would like 2000% on a laptop or desktop


JA: Is there better wording we should be using Josh and Andrew?


JO: I don't think we're going to redefine the terminology


<alastairc> https://github.com/w3c/wcag21/issues/58



JO: If we're finding that it's not working or people simply aren't getting
it, we'd need to find way to do better


<Joshue108> +1 yup this is a good idea


AC: There are some techniques we need to pin down to support this


<laura> “Mechanism is available" language that gives a misconception that
widgets are required.


<allanj> jo: safari reader view


JO: Distinction here is user overriding the author preference
... I think it's good, taking user control


AC: It does seem this mechanism language isn't enough at the moment


JO: Anything created or chosen as a user preference would seem good, and
should be supported and labeled as such


<Zakim> shawn, you wanted to say we need to address these misunderstandings
- now within AG WG *and* in the documentation (Understanding, etc.) for
others


<Joshue108> can I ask how the user will activate this single column view?


SH: Step 1, we need to clarify some of these things and get people to
understand and share in them


<alastairc> NB: I think there is a lot of work to do, to define how to test
and have a baseline of the user-agent end.


WD: I think we want to avoid the word "preference" as we're talking about
needs here


<alastairc> Josh: Try the right-hand link on here:
https://alastairc.ac/tests/layouts/pixels.html



WD: Spacing, Font Family and Font Size, if you take a page and make it
bigger as-is, you'll need to make it much bigger if you don't alter
Spacing, Font Family, etc.
... Color can also be very influential in that
... These are like really being able to read vs. catching a snippet here
and a snippet there
... At the element level, most of the supports for 1.3.1 will do the job
for most of these


<Joshue108> Ok - I see the kind of think that Alastair has developed in
this example - that's good.


WD: Most menus where I've run in to problems do fixed pixel rates that
don't account for growth of size of elements in menu


<Joshue108> But if that isn't a mechanism, are we asking for some HTML
language level changes to do this?


WD: Even if writing an extension, you have to be able to look at those
elements and tell what they're about


<Joshue108> Or is there a preferred term the LVTF have come up for as an
alternative to mechanism?


<alastairc> Wayne: try this menu for your testing:
https://www.theguardian.com/uk Note that it can scroll horizontally!


WD: I think there really are things that the author can do within context
to make certain things possible


JO: Wayne, some things I'm seeing in code suggestions, do you want to see
changes in the language / HTML level, I'm confused as to what's being asked


WD: I'm really talking about what authors can do. In HTML there are so many
things they can do to break


<laura> CSS !important Spacing Test:
http://www.d.umn.edu/~lcarlson/wcagwg/tests/user_styles/important_spacing.html



<alastairc> laura: was the result that it was ok?


<alastairc> i.e. could be over-ridden


WD: You cannot control when someone just drops some new code in the middle
with localized stuff that can't be changed


<laura> Yes: in IE and Safari


WD: For color, using background image to carry your color, you have to
remove that image


<Glenda> Wayne, can we read your paper on Lexical Enlargement (LexE)?


<laura> alastairc: see results section


JO: Seems to me that Alastairs Linearize page is nice and simple, can this
technique be supported to be added in other pages - Linearization?


JA: Other mechanize that is available is Mobile View


AC: To Josh's point about techniques, we do need SC to hang these
techniques off of
... Will need a text for when Javascript is using CSS


technique not text


AC: Browser extensions could be among better techniques


JO: Agree on need of SC to hang these off


AC: We have well defined user requirements, so a matter of going through
process of hashing out techniques


JA: By requirements do you mean our SC language?


AC: yes


WD: I think Font Family is another example where techniques will help


<alastairc> Note to self: Put the bookmarklet on github so anyone can use
or contribute to it.


WD: In a page that isn't changing all the time, if you run a program
through it, you will get to elements where visual interface is achieving
1.3.1
... It's unfortunate that we don't have ARIA parameters for people to drop
local meaning as to what they're doing
... Font Family: following 1.3.1 is kind of recognizing that the ability to
change font family is important to people, even if it wasn't called out in
1.3.1


JO: Requires more discussion, we don't want to break things by changes we
make


JA: Any issues to bring up from the SC managers?


GS: I've been mentally struggling with pixel is not a pixel, have gotten
stuck and reaching out to Patrick Lauke


AC: If you cannot get Patrick, I have a good handle on it also
... I am listed as being on three, I am on two at the moment


<laura> Issue 78 "Spacing" Report


<laura> http://www.d.umn.edu/~lcarlson/wcagwg/spacing/report.html



<laura> Issue 78 Organized Comments


<laura> http://www.d.umn.edu/~lcarlson/wcagwg/spacing/comments.html



LC: For spacing, I put together report for WCAG group on Tues and have
organized comments
... Biggest issue is organizing techniques


<alastairc> Laura: If we take my bookmarklet and convert it to do spacing,
we should be able to find issues & therefore techniques quickly.


<allanj> +1 modify Alistair bookmarklet


<allanj> MS Edge removed user stylesheets


<allanj> open item 4


<laura> https://github.com/w3c/wcag21/issues/76



<allanj> http://www.tsbvi.edu/technology-items/5343-lvtf



JA: If I print at 300 or 400% you can do that in almost every browser, I
found pages where they are broken with overlap text and truncation, which I
believe is all in the CSS
... Rewriting the SC a bit to accept whatever author has done, should at
least be able to print out without the overlap, breaking
... Tested browsers will go to 200%, but you can go larger by choosing
custom


SH: has spacing examples can share


WD: This is almost like small mobile device issues
... What I do with paper is get it to 200% and then use a magifying glass
... That is another device dependent thing that we should think about


Summary of Action Items
Summary of Resolutions
                                                                                       
                    Erich Manser                                                       
                    IBM                                                                
                    Accessibility,                                                     
                    IBM Research                                                       
                    Littleton,                                                         
                    MA / tel:                                                          
                    978-696-1810                                                       
                    Search for                                                         
                    accessibility                                                      
                    answers                                                            
                                                                                       
                                                                                       
                                                                                       
                                                                                       
                                                                                       
                                                                                       
                                                                                       



You don't need eyesight to have vision.