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 15:14:37 -0500
Message-ID: <CAOavpvcxhHEXxV6PNWohyeBmVwZK9iYB9B5=DPrCR+dfBk4jQw@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 Greg,

How about "linearized text"? "Text meant to be read in a sequential fashion..."


"sequential text"? "Text meant to be read in a linearized fashion..."

Thanks for all your work on this.

Best Regards,

On 6/22/15, Gregg Vanderheiden <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>
>> [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>
>> [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>
>> [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>
>> [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>
>> On 6/22/15, 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
>>>> 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 <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>> | Twitter
>>>> <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>> | Blog
>>>> <http://www.ssbbartgroup.com/blog <http://www.ssbbartgroup.com/blog>> |
>>>> Newsletter <http://eepurl.com/O5DP <http://eepurl.com/O5DP>>
>>>> From: David MacDonald [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>>
>>>> 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>>
>>>> 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>>>
>>>> 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
>>>> 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>>
>>>> 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>>>
>>>> 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
Received on Monday, 22 June 2015 20:15:15 UTC

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