Re: Screen Magnification

I thought of that too   —   but I couldn’t figure out how to make that work. 

Can you see if you can find the wording?  
 (be sure it doesn’t accidentally include charts and tables and other things that are destroyed if reflowed)



gregg

----------------------------------
Gregg Vanderheiden
gregg@raisingthefloor.org




> On Jun 22, 2015, at 12:02 PM, Mitchell Evan <mtchllvn@gmail.com> wrote:
> 
> Thank you for excellent framing of the problem.
> 
> Responding to this:
> >>> If we were to limit WCAG to HTML only — then we could address it for some types of content.. 
> but that we can’t create guidelines that only work for HTML
> <<<
> 
> 
> Agreed, but we could require reflow the way we currently require zoom.
> 
> "If the author is using a technology whose user agents do not provide zoom support, the author is responsible to provide this type of functionality directly or to provide content that works with the type of functionality provided by the user agent."
> 
> 
> 
> http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-scale.html <http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-scale.html>
> 
> On Mon, Jun 22, 2015, 9:18am Gregg Vanderheiden <gregg@raisingthefloor.org <mailto:gregg@raisingthefloor.org>> wrote:
> 
> OH   One thing to not miss (and perhaps I didn’t make enough of a point of it) is that 
> 
> This issue cannot be solved from the authoring end alone  
> 
> I think the hardest part this issue is that 
> 
> the problem can’t be solved by content authors (though they can make it easier or more difficult.   The readers/browsers have as much or more to do with it.    
> 
> 
> This is one reason it could not be solved by WCAG —  or any content guidelines
> 
> since the author doesn’t have control of many technologies’ display. 
> 
> (If we were to limit WCAG to HTML only — then we could address it for some types of content.. 
> 
> but that we can’t create guidelines that only work for HTML).
> 
> 
> Soooo 
> 
> Perhaps we need to have TWO guidelines
> 
> User Agents (document presentation software) must/shall allow “running text”  (text that is meant to be read as a linear narrative - and where text position does not convey meaning)  to be reflowed as fonts are enlarged or the viewing window is reduced. Authors must/shall not prevent user agents from reflowing  “running text” in their content (text that is meant to be read as a linear narrative - and where text position does not convey meaning).  
> 
> Again these could be tightened up a bit.
> 
> NOTE:  that setting page widths in HTML currently causes text to not reflow (BUT IT DOES NOT HAVE TO).  Browsers could easily have an optional setting that would ignore this markup (at user request) and reflow the page.  
> 
> Thus, including page width (where the author thought it important for most users) would NOT be a violation of the guideline IF BROWSERS had such a setting to allow it to be overridden by users who need it. IT would not have to be ALL browsers.  It could be just one commonly available one that users COULD use if the needed this ability.  (although best if all did - but for 508 it could be the one that is provided to the US Gov for its employees and its public browsing equipment)
> 
> Without that optional override setting in some available browser, such a requirement would mean that NO Page could use page width — which I think would cause problem in some places.    
> 
> 
> This is my first pass at the above text —
> 
> so comments are invited  (as always - but especially here). 
> 
> 
> gregg
> 
> ----------------------------------
> 
> Gregg Vanderheiden
> 
> gregg@raisingthefloor.org <mailto:gregg@raisingthefloor.org>
> 
> 
> 
> On Jun 22, 2015, at 7:16 AM, Jonathan Avila <jon.avila@ssbbartgroup.com <mailto:jon.avila@ssbbartgroup.com>> wrote:
> 
> >>panning in the direction that text is read shall not be required when enlarging text (content?) that is meant to be read in a linear fashion.  
> 
>  
> +1 as well.  Gregg’s post frames the problem and proposed guidance well.
> 
>  
> 
> Jonathan
> 
>  
> -- 
> Jonathan Avila 
> Chief Accessibility Officer
> SSB BART Group 
> jon.avila@ssbbartgroup.com <mailto:jon.avila@ssbbartgroup.com>
> Phone 703.637.8957  
> Follow us: Facebook <http://www.facebook.com/#!/ssbbartgroup> | Twitter <http://twitter.com/#!/SSBBARTGroup> | LinkedIn <http://www.linkedin.com/company/355266?trk=tyah> | Blog <http://www.ssbbartgroup.com/blog> | Newsletter <http://eepurl.com/O5DP>
>  
> From: David MacDonald [mailto <mailto:david100@sympatico.ca>:david100@sympatico.ca <mailto:david100@sympatico.ca>] 
> Sent: Monday, June 22, 2015 6:21 AM
> To: Gregg Vanderheiden
> Cc: Wayne Dick; IG - WAI Interest Group List list; GLWAI Guidelines WG org
> Subject: Re: Screen Magnification
> 
>  
> >>>panning in the direction that text is read shall not be required when enlarging text (content?) that is meant to be read in a linear fashion.  
> 
>  
>  
> +1
> 
> Cheers,
> 
> David MacDonald
> 
>  
> CanAdapt Solutions Inc.
> 
> Tel:  613.235.4902
> 
> LinkedIn <http://www.linkedin.com/in/davidmacdonald100>
> www.Can-Adapt.com <http://www.can-adapt.com/>
>   
>   Adapting the web to all users
> 
>             Including those with disabilities
> 
>  
> If you are not the intended recipient, please review our privacy policy <http://www.davidmacd.com/disclaimer.html>
>  
> On Mon, Jun 22, 2015 at 12:30 AM, Gregg Vanderheiden <gregg@raisingthefloor.org <mailto:gregg@raisingthefloor.org>> wrote:
> 
> Just found this in my drafts folder — never sent.   so sending now - though some if it is OBE perhaps.  Other parts are of interest in think. 
> 
>  
> Read it - and then have at it if you disagree (or agree) (or have other better thoughts)
> 
>  
> this is an important topic.
> 
>  
> Gregg
> 
>  
>  
>  
>  
>  
>  
> Hi Wayne,
> 
>  
>  
> I agree    that  an ability to make text larger -  WHILE RETAINING A DISPLAY THAT DOES NOT REQUIRE PANNING  is far superior that magnification (where usable)
> 
>  (i.e. using larger screen,  enlarging content with reflow,  etc. —  are better than magnifying when you can use them ). 
> 
>         (And I add 5 exclamations points to that.   !!!!!)
> 
>  
> I also agree  that those who ONLY use/want magnification are a small portion of the overall population that need larger text. 
> 
>  
>  
>  
>  
>  
> However  -  I think we need to be careful we are not overly critical of magnification and APIs .    Magnification is ESSENTIAL for SOME PEOPLE and for SOME APPLICATIONS. 
> 
>  
>  Things I think we need to keep in mind when talking about magnification vs “enlarge and reflow” include: 
> 
>  
> everyone needs magnification sometimes  — (see below)  so magnification is actually used by more people (although some only use it for certain things).magnifiers are not just about enlarging and smoothingAPIs are important to usethe way to emphasize the importance of one technique is not to say it is more important than another. "enlarge and reflow" is not always a good idea for all content - it destroys some types of contentyou can’t require that something be done everywhere  -  just because it is really important sometimes.  it has to be possible everywhere (useful everywhere) or you cannot require it.generally it is better to say what must be possible rather than how to do it
> 
>  
>  
>  
> Detail and rationale for each 
> 
>  
> 1)  Everyone needs magnification sometimes.
> 
>  
> enlarge+reflow is a really powerful technique for running text  — but you can’t use it for  maps, charts, photographs, artwork, diagrams, schematics, some types of web app interfaces and other visio-spatial information.  So even those people who mostly use and/or prefer enlarge and reflow, will need / prefer to use magnification for SOME TYPES of content.    (Everyone needs to use zoom/magnification sometimes)
> 
>  
> 2) magnifiers are not just about enlarging and smoothing
> 
>  
> magnifiers do enlarge (and hopefully smooth or retain smooth) edges as they can (though very smooth edges are often more important to people with good vision).   However it is also important for people with low vision to be able to navigate or track navigation and events on the screen  (and things on screen but off screen when enlarged — or that would move off screen while entering text for example.)    So the ability of a magnifier to understand what is going on on screen is important to magnifier operation — and gets more important a higher magnifications 
> 
>  
> 3) APIs are important
> 
>  
> The best way to say "APIs are important” is to say that it is important that all information is “programmatically determinable”. That is, that all information can be determined by software (AT) including changes to the information.    This is the base requirement.   Not all information is available via an API (a standard way to pass information between software),  but where APIs can be used they are usually the most powerful ways.  And the most reliable.  Since magnifiers need to get information from the browser to work most effectively, APIs are important to magnifiers
> 
>  
> 4) the way to emphasize the importance of one technique is not to say it is more important another 
> 
>  
> Enlarge and reflow is incredibly important and you (we all) need to continue to advocate for it. But we should not downplay the approaches needed by others in our questWe are all worried about people with disabilities having their needs addressed.  They represent a “tail” of the population and are not always considered as they should be because there are fewer of them (and if you think about any single type of disability the number is even smaller.)  But as we focus on one disability (one tail) we need to be sure we don’t downplay the importance of another group (tail) just because it is smaller. the day we say “this disability is more important than that disability because it is larger” is the day we fall into the same argument as “people without disabilities are more important than people with disabilities because they are larger”   We need to think of all people with all disabilities as being important regardless of size.  
> 
>  
> 5)  "enlarge and reflow" is not always a good idea - destroys some types of content
> 
>  
> as note above, enlarge and reflow is not always a good idea for all content in fact it completely destroys some types of content (a map, a schematic etc)and it can make other types of information or interfaces harder to useThat said — enlarge and reflow   and responsive design in general  — can and should be applied in many more places than it is.   And we need to push people to learn how  (and show them how).    But we must also respect and admit that there are places where it doesn’t make sense — and then held them figure out how to tell the difference. 
> 
>  
> 6)  We can’t require that something be done everywhere  -  just because it is really important sometimes.  
> 
>  
> Not matter how important something is — it can’t be a flat requirement for content if it can’t be done for all content. It has to be possible everywhere (useful everywhere) or you cannot require it (as a flat requirement) (i.e. it must always be met for all content).There are many examples in WCAG where things are required — but only after the areas where they don’t work are identified and listed as exceptions. If “enlarge and reflow” is to be required then we either need to a) describe the circumstances when the rule should apply, or b) the circumstances where it would not.  And the circumstances need to be very clear, objective, and accurate/correct/comprehensive.  
> 
>  
> 7) generally it is better to say what must be possible rather than how to do it
> 
>  
> in WCAG and other accessibility standards, we have found that it is better to say what must be possible rather than specify how to do itin this manner, new technologies can be introduced (where a technique cannot be used) and the requirement can still applynew techniques can be introduced that would achieve the same result — and it wouldn’t be disallowed because another technique is requiredfor example(s) Saying that “content must make sense if the stylesheet is changed or removed” won’t make sense if the technology has no style sheetsSaying that you must use technique A — doesn’t allow a later, better technique to be used.Saying that you must use technique A - won’t allow a technology to be used at all that doesn’t support that technique even though the effect might be achieved in another wayto remain timeless think of the problem and not the solution.in <http://solution.in/> this case perhaps the problem is panning. 
> 
>  
>  
> Possible language
> 
>  
>  I don’t have the right language — but here are some attempts to get us thinking
> 
> (I am numbering them ONLY to facilitate discussion.  they are not in any other order)
> 
>  
> Panning shall/must not be required when enlarging text (content?) that is meant to be read in a linear fashion.Content that is meant to be presented/viewed/read in a linear fashion shall not require panning when it is enlarged or the viewport is restricted horizontally 
> 
>  
> hmmm. I just realized that we alway pan (scroll) when we read even if it reflows.  We just want to avoid panning in one dimension. (e.g vertical scrolling is ok but not horizontal scrolling for left to right (and right to left) languages.   
> 
> But if we say “doesn’t require ‘horizontal scrolling’ then we are forgetting that not all text is read horizontally.
> 
>  
> So …..
> 
>  
> that gives us something like 
> 
>  
> panning in the direction that text is read shall not be required when enlarging text (content?) that is meant to be read in a linear fashion.  
> 
>  
> (and now we see why requirements and provisions in WCAG and other standards can sometimes sound technical and complicated in order to be accurate across technologies, languages, uses etc.) 
> 
>  
>  
>  
> RE your comments on WAI
> 
>  
> perhaps a better way to summarize the problem, which emphasized the importance of “enlarge and wrap” without dissing magnification might be:
> 
>  
> Magnification is very important for some individuals with severe visual disabilities, and it is important to everyone for those cases where the layout of the content must be preserved (maps, diagrams, tables, pictures, and some interfaces).   But for text that is read linearly, enlarging text in a fashion that requires the lines of text to go offscreen (so the person has to keep scrolling the screen back and forth to read each line of text) is extraordinarily difficult and inefficient for all (and impossible for those without good physical control or who have visual tracking problems).   
> 
>  For all content that is meant to be read linearly, it is therefore very important that the reader be able to cause the content to reflow as it is enlarged relative to the page width, such that text does not move offscreen where it would require scrolling the page back and forth to read the content. 
> 
>  
> (note that the above text works for both horizontal and vertically presented text)
> 
>  
> (Note also that the above would put requirements on BOTH the content author  — and also (and perhaps more importantly) on the user agent.  For example it is not possible to require this of a content author if it user agent did not support the ability. )
> 
>  
> In WCAG for example - it was not possible to require this of content authors — without restricting the technologies to which WCAG would apply. 
> 
>  
> 
>  
>  
> So please continue to advocate for reflow etc where it is possible / appropriate but:
> 
>  
> be careful to not interpret things said in a wrong way or to assume that those who advocate for magnifiers for those that need them (or for everyone or some types of content) believe that they are the best solution for all users and all types of content.remember that there are many content types where reflow is not the answer  (  charts, maps, pictures, artwork, diagrams, schematics, some web app interfaces and other visio-spatial information ) and a requirement that they reflow is not only not possible but not useful. 
>  
> 
>  
> (also we all need to remember to not paint a whole working group by the comments of some — or even paint a person's point of view by a single comment they make.       I know if have written things that sounded different than what I mean or believe.  Just bad wording, or ambiguous wording, or even a brain short-circuit.   (in fact there may be some sentence above that I didn’t write correctly.) 
> 
>  
>  
> But do keep up your crusade for reflow.    
> 
>  
> Perhaps it needs to focus on players/viewers though - rather than authors?  ( or before authors are able to do anything about it?)
> 
>  
>  
> Good luck 
> 
>  
> Ciao
> 
> gregg
> 
>  
> ----------------------------------
> 
> Gregg Vanderheiden
> 
> gregg@raisingthefloor.org <mailto:gregg@raisingthefloor.org>
>  
>  
>  
> On Apr 22, 2015, at 11:11 PM, Wayne Dick <waynedick@knowbility.org <mailto:waynedick@knowbility.org>> wrote:
> 
>  
> For some reason not based on usage, the WAI has zeroed in on screen magnification as some kind of primary assistive technology for people with partial sight.  This is promoted in the Accessibility API Mappings 1.1 when screen magnification is listed as the first type of assistive technology.  This gives a class of technology with niche uses at most a  prominence it does not deserve. 
> 
> Screen magnification is an extremely poor example of technology to use in the context of web technology.  This is because screen magnification ignores the DOM structure and the entire accessibility API.  Some screen magnifiers make feeble attempts at including this technology but their efforts are clumsy at best.
> 
> Please WAI, stop with trying to promote screen magnification as anything other that a spot solution that works in limited cases for a small minority of people with visual impairments. HTML, CSS, the DOM and all accessibility APIs could be dropped and screen magnification would suffer limited inconvenience. It has no place in the Accessibility API Mappings 1.1.
> 
> That may sound harsh, but I cannot think of a kinder way to put it.  I am grateful for the developers of this technology but its importance is just not as significant as the WAI seems to believe.  Shawn's surveys shows this.  Comparing the purchases of screen magnifiers to the population of people with partial sight also demonstrates this.  Most people with low vision do not avoid screen magnification technology because they are Luddites, as normal people frequently accuse us of being. We use it in limited ways because its use has limited value. I hope the WAI internalizes this message and stops presenting screen magnification as a viable solution for more than a small subset of people with low vision.
> 
>  
>  Wayne
> 
> 
> -- 
> Mitchell Evan
> mtchllvn@gmail.com <mailto:mtchllvn@gmail.com>
> +1 (510) 375-6104
>