Re: Screen Magnification

+1

Sent from my iPad

On Jun 22, 2015, at 8:19 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: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:


  1.  everyone needs magnification sometimes  — (see below)  so magnification is actually used by more people (although some only use it for certain things).
  2.  magnifiers are not just about enlarging and smoothing
  3.  APIs are important to use
  4.  the way to emphasize the importance of one technique is not to say it is more important than another.
  5.  "enlarge and reflow" is not always a good idea for all content - it destroys some types of content
  6.  you 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.
  7.  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 quest
  *   We 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 use
  *   That 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 it
  *   in this manner,

     *   new technologies can be introduced (where a technique cannot be used) and the requirement can still apply
     *   new techniques can be introduced that would achieve the same result — and it wouldn’t be disallowed because another technique is required
     *   for 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 sheets
        *   Saying 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 way

  *   to remain timeless think of the problem and not the 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)


  1.  Panning shall/must not be required when enlarging text (content?) that is meant to be read in a linear fashion.
  2.  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


  1.  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:


  1.  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.
  2.  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