Re: Screen Magnification

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
>>> 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>>
>>> 
>>> 
>>> 
>>> 
>>> 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

Received on Monday, 22 June 2015 17:51:31 UTC