- From: Gregg Vanderheiden <gregg@raisingthefloor.org>
- Date: Mon, 22 Jun 2015 15:58:23 -0500
- To: Laura Carlson <laura.lee.carlson@gmail.com>
- Cc: IG - WAI Interest Group List list <w3c-wai-ig@w3.org>, GLWAI Guidelines WG org <w3c-wai-gl@w3.org>
- Message-Id: <8766D9E5-8BDC-4653-B859-14D3B6E93BF8@raisingthefloor.org>
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
Received on Monday, 22 June 2015 20:58:57 UTC