W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > April to June 2015

Re: Screen Magnification

From: Laura Carlson <laura.lee.carlson@gmail.com>
Date: Mon, 22 Jun 2015 16:21:42 -0500
Message-ID: <CAOavpveSqmOPNvNf8kdgCB0-G8yve9Ax=GgYNXC8x_1gYn8Xvg@mail.gmail.com>
To: Gregg Vanderheiden <gregg@raisingthefloor.org>
Cc: IG - WAI Interest Group List list <w3c-wai-ig@w3.org>, GLWAI Guidelines WG org <w3c-wai-gl@w3.org>
Hi Gregg,

Good point. "Linearized text, "running text" and "body text" are all
likely to confuse.
* running text (concerned that this will mean  marquee or scrolling
text  to developers which is NOT what we mean)
* body text   (but concerned that this is anything between <body>  and
</body> which is NOT what we mean
* linearized sounds like it was something else - and someone did
something to make it linear.

So remaining possibilities:

* "linear text"
* "sequential text"
* "prose text" Question: would "prose text" rule out poetry? We
wouldn't want to do that.
* or something better that anyone can think of.

Best Regards,
Laura


On 6/22/15, Gregg Vanderheiden <gregg@raisingthefloor.org> wrote:
> Hmmm linearized sounds like it was something else — and someone did
> something to make it linear.
>
> “linear text”  ???
>
> not sure anyone will know what that is (except us that are already on
> board)
>
> it would have to be something that was unambiguous —(or else we can define
> it)
>
> I think running is better then but not sure…
>
>
> any other candidates?
> linear text
> running text
> body text   (but concerned that this is anything between <body>  and </body>
>  which is NOT what we mean
> prose text
> ??
>
> gregg
>
> ----------------------------------
> Gregg Vanderheiden
> gregg@raisingthefloor.org
>
>
>
>
>> On Jun 22, 2015, at 3:14 PM, Laura Carlson <laura.lee.carlson@gmail.com>
>> wrote:
>>
>> Hi Greg,
>>
>> How about "linearized text"? "Text meant to be read in a sequential
>> fashion..."
>>
>> Or
>>
>> "sequential text"? "Text meant to be read in a linearized fashion..."
>>
>> Thanks for all your work on this.
>>
>> Best Regards,
>> Laura
>>
>> On 6/22/15, Gregg Vanderheiden <gregg@raisingthefloor.org
>> <mailto:gregg@raisingthefloor.org>> wrote:
>>> Good point
>>>
>>> I wanted it to be something different than “all text within the  <body>
>>> markup though —so didn’t think I could use that term
>>>
>>> anyone got a better term than  “running text”  or “text meant to be read
>>> in
>>> an linear fashion without spatial information or spatial relationships
>>> ……”
>>>
>>>
>>>
>>> gregg
>>>
>>> ----------------------------------
>>> Gregg Vanderheiden
>>> gregg@raisingthefloor.org
>>>
>>>
>>>
>>>
>>>> On Jun 22, 2015, at 12:35 PM, Laura Carlson
>>>> <laura.lee.carlson@gmail.com>
>>>> wrote:
>>>>
>>>> Hi Gregg and all,
>>>>
>>>> Those are two great guidelines. Thank you.
>>>>
>>>> It may be good to consider the definition of "running text" so
>>>> developers and user agent vendors do not confuse it with
>>>> marquee/scrolling text. I've come across it meaning both body text [1]
>>>> [2] [3] and it meaning marquee or scrolling text [4] [5].
>>>>
>>>> Maybe use "body text" or something else?
>>>>
>>>> Best Regards,
>>>> Laura
>>>>
>>>> [1] "The body of text, as distinct from headings, footnotes, diagrams
>>>> and other added material."
>>>> https://en.wiktionary.org/wiki/running_text
>>>> <https://en.wiktionary.org/wiki/running_text
>>>> <https://en.wiktionary.org/wiki/running_text>>
>>>>
>>>> [2] "the body of text in a newspaper, magazine, or the like, as
>>>> distinguished from the heads, illustrations, etc."
>>>> http://dictionary.reference.com/browse/running+text
>>>> <http://dictionary.reference.com/browse/running+text>
>>>> <http://dictionary.reference.com/browse/running+text
>>>> <http://dictionary.reference.com/browse/running+text>>
>>>>
>>>> [3] "Most documents consist almost entirely of running text--words
>>>> formed into sentences, which are in turn formed into paragraphs--and
>>>> the example file is no exception."
>>>> http://www.math.wsu.edu/kcooper/M300/essential/node6.html
>>>> <http://www.math.wsu.edu/kcooper/M300/essential/node6.html>
>>>> <http://www.math.wsu.edu/kcooper/M300/essential/node6.html
>>>> <http://www.math.wsu.edu/kcooper/M300/essential/node6.html>>
>>>>
>>>> [4] "Running Text is a simple tool to let your message scrolling
>>>> conveniently. It can be used as a billboard for displaying slogan to
>>>> your customer, or as a text board for showing message to your friend."
>>>> https://play.google.com/store/apps/details?id=com.ykart.tool.runningtext
>>>> <https://play.google.com/store/apps/details?id=com.ykart.tool.runningtext>
>>>> <https://play.google.com/store/apps/details?id=com.ykart.tool.runningtext
>>>> <https://play.google.com/store/apps/details?id=com.ykart.tool.runningtext>>
>>>>
>>>> [5] http://netgator.blogspot.com/2010/05/how-to-marquee-any-text.html
>>>> <http://netgator.blogspot.com/2010/05/how-to-marquee-any-text.html>
>>>> <http://netgator.blogspot.com/2010/05/how-to-marquee-any-text.html
>>>> <http://netgator.blogspot.com/2010/05/how-to-marquee-any-text.html>>
>>>>
>>>> On 6/22/15, Gregg Vanderheiden <gregg@raisingthefloor.org
>>>> <mailto:gregg@raisingthefloor.org>
>>>> <mailto: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>
>>>>>> <mailto:jon.avila@ssbbartgroup.com
>>>>>> <mailto:jon.avila@ssbbartgroup.com>>
>>>>>> <mailto:jon.avila@ssbbartgroup.com <mailto:jon.avila@ssbbartgroup.com>
>>>>>> <mailto:jon.avila@ssbbartgroup.com
>>>>>> <mailto:jon.avila@ssbbartgroup.com>>>
>>>>>> Phone 703.637.8957
>>>>>> Follow us: Facebook <http://www.facebook.com/#!/ssbbartgroup
>>>>>> <http://www.facebook.com/#!/ssbbartgroup>
>>>>>> <http://www.facebook.com/#!/ssbbartgroup
>>>>>> <http://www.facebook.com/#!/ssbbartgroup>>> | Twitter
>>>>>> <http://twitter.com/#!/SSBBARTGroup
>>>>>> <http://twitter.com/#!/SSBBARTGroup>
>>>>>> <http://twitter.com/#!/SSBBARTGroup
>>>>>> <http://twitter.com/#!/SSBBARTGroup>>> | LinkedIn
>>>>>> <http://www.linkedin.com/company/355266?trk=tyah
>>>>>> <http://www.linkedin.com/company/355266?trk=tyah>
>>>>>> <http://www.linkedin.com/company/355266?trk=tyah
>>>>>> <http://www.linkedin.com/company/355266?trk=tyah>>> | Blog
>>>>>> <http://www.ssbbartgroup.com/blog <http://www.ssbbartgroup.com/blog>
>>>>>> <http://www.ssbbartgroup.com/blog <http://www.ssbbartgroup.com/blog>>>
>>>>>> |
>>>>>> Newsletter <http://eepurl.com/O5DP <http://eepurl.com/O5DP>
>>>>>> <http://eepurl.com/O5DP <http://eepurl.com/O5DP>>>
>>>>>>
>>>>>> From: David MacDonald [mailto:david100@sympatico.ca
>>>>>> <mailto:david100@sympatico.ca>
>>>>>> <mailto: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
>>>>>> <http://www.linkedin.com/in/davidmacdonald100>
>>>>>> <http://www.linkedin.com/in/davidmacdonald100
>>>>>> <http://www.linkedin.com/in/davidmacdonald100>>>
>>>>>> www.Can-Adapt.com <http://www.can-adapt.com/>
>>>>>> <http://www.can-adapt.com/ <http://www.can-adapt.com/>>
>>>>>> <http://www.can-adapt.com/ <http://www.can-adapt.com/>
>>>>>> <http://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
>>>>>> <http://www.davidmacd.com/disclaimer.html>
>>>>>> <http://www.davidmacd.com/disclaimer.html
>>>>>> <http://www.davidmacd.com/disclaimer.html>>>
>>>>>>
>>>>>> On Mon, Jun 22, 2015 at 12:30 AM, Gregg Vanderheiden
>>>>>> <gregg@raisingthefloor.org <mailto:gregg@raisingthefloor.org>
>>>>>> <mailto:gregg@raisingthefloor.org <mailto:gregg@raisingthefloor.org>>
>>>>>> <mailto:gregg@raisingthefloor.org <mailto:gregg@raisingthefloor.org>
>>>>>> <mailto: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 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
>>>>>> 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)
>>>>>>
>>>>>> 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>
>>>>>> <mailto:gregg@raisingthefloor.org <mailto:gregg@raisingthefloor.org>>
>>>>>> <mailto:gregg@raisingthefloor.org <mailto:gregg@raisingthefloor.org>
>>>>>> <mailto:gregg@raisingthefloor.org
>>>>>> <mailto:gregg@raisingthefloor.org>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Apr 22, 2015, at 11:11 PM, Wayne Dick <waynedick@knowbility.org
>>>>>> <mailto:waynedick@knowbility.org>
>>>>>> <mailto:waynedick@knowbility.org <mailto:waynedick@knowbility.org>>
>>>>>> <mailto:waynedick@knowbility.org <mailto:waynedick@knowbility.org>
>>>>>> <mailto: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
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Laura L. Carlson
>>>
>>>
>>
>>
>> --
>> Laura L. Carlson
>
>


-- 
Laura L. Carlson
Received on Monday, 22 June 2015 21:22:15 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 16 January 2018 15:34:19 UTC