Re: Screen Magnification

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

On Mon, Jun 22, 2015, 9:18am Gregg Vanderheiden <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



 On Jun 22, 2015, at 7:16 AM, Jonathan Avila <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

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>
:david100@sympatico.ca <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> 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 **smoothing**APIs**
are important* to use*the** 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 content*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.*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 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







 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



 --

Mitchell Evan
mtchllvn@gmail.com
+1 (510) 375-6104