- From: Laura Carlson <laura.lee.carlson@gmail.com>
- Date: Mon, 22 Jun 2015 15:14:37 -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 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> 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 >>>> 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 > > -- Laura L. Carlson
Received on Monday, 22 June 2015 20:15:15 UTC