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



*Can**Adapt* *Solutions Inc.*

Tel:  613.235.4902

LinkedIn <http://www.linkedin.com/in/davidmacdonald100>

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> 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
>
>
>
>
> On Apr 22, 2015, at 11:11 PM, Wayne Dick <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
>
>
>
>