- From: Laura Carlson <laura.lee.carlson@gmail.com>
- Date: Mon, 22 Jun 2015 16:21:42 -0500
- 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