- From: David MacDonald <david100@sympatico.ca>
- Date: Wed, 11 Jan 2017 13:21:36 -0500
- To: John Foliot <john.foliot@deque.com>
- Cc: Makoto UEKI <ueki@infoaxia.com>, Shwetank Dixit <Shwetank@barrierbreak.com>, "Patrick H. Lauke" <redux@splintered.co.uk>, WCAG <w3c-wai-gl@w3.org>
- Message-ID: <CAAdDpDZbWKHnoU_ka_WHW4mztyBFbM8ks7P76L_aGaRXddSSjA@mail.gmail.com>
CSS hyphenation (when it is supported) offers the author control, which is fine... Cheers, David MacDonald *Can**Adapt* *Solutions Inc.* Tel: 613.235.4902 LinkedIn <http://www.linkedin.com/in/davidmacdonald100> twitter.com/davidmacd GitHub <https://github.com/DavidMacDonald> 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> On Wed, Jan 11, 2017 at 12:28 PM, John Foliot <john.foliot@deque.com> wrote: > > most (all) bowsers don't add hyphens > > Sorry David, I have to disagree: most browsers today support the CSS > hyphens attribute (https://www.w3.org/TR/css-text/#hyphens-property), > confirmed by CanIUse here: http://caniuse.com/#search=hyphens > > See also: > http://blog.fontdeck.com/post/9037028497/hyphens > https://developer.mozilla.org/en-US/docs/Web/CSS/hyphens > https://css-tricks.com/almanac/properties/h/hyphenate/ > > JF > > On Wed, Jan 11, 2017 at 11:08 AM, David MacDonald <david100@sympatico.ca> > wrote: > >> > I would propose we look to Root EMS instead for at least part of this >> proposal, and that we also include a magnification point (200%? 400%?) as >> also part of the requirement: >> >> I think the latest proposal addresses the magnification issue by >> requiring that the SC be met without zooming text. The downside of REMs are >> that it is harder to understand, it is a specific technology, and it is a >> relative measurement. Patrick, Jon A., what are your thoughts? >> >> I would also like Makoto and Swetank to respond to the hyphenation >> situation that most (all) bowsers don't add hyphens, and that CSS can be >> use to override any hyphenation. >> >> Cheers, >> David MacDonald >> >> >> >> *Can**Adapt* *Solutions Inc.* >> >> Tel: 613.235.4902 <(613)%20235-4902> >> >> LinkedIn >> <http://www.linkedin.com/in/davidmacdonald100> >> >> twitter.com/davidmacd >> >> GitHub <https://github.com/DavidMacDonald> >> >> 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> >> >> On Wed, Jan 11, 2017 at 11:24 AM, John Foliot <john.foliot@deque.com> >> wrote: >> >>> David wrote: >>> >>> > We have an established precedent in 1.4.8 of using characters to >>> measure line length. >>> >>> Hi David, >>> >>> While we may have precedent there, SC 1.4.8 is a AAA Success Criteria, >>> and I am hard-pressed personally to recall a site that meets (and reports >>> compliance to) that SC consistently. As we've seen, "character" is a very >>> imprecise unit of measurement. >>> >>> I think we need to step back a bit; what is the real goal we are trying >>> to achieve here? I don't think it has anything to do with actual character >>> count (per-se), but rather that we need developers to not break text >>> re-flow (perhaps to a minimum of 25 REMs - Root EMs >>> <https://snook.ca/archives/html_and_css/font-size-with-rem>). >>> Level-set: LVTF, is this the real "goal" here? >>> >>> However, given fixed view-port sizes and magnification there will >>> necessitate a trade-off, or else I could envision developers will create >>> one line in their document at font-size:40px - perhaps an h1 - and then use >>> that as the 'measuring point': 25 X 40px = 1000px, which, as a "baseline, >>> would then "allow" paragraph text at 16px. to far exceed the 25 character >>> count being proposed (1000 / 16 = 62.5 "characters") It is for this reason >>> that I would propose we look to Root EMS instead for at least part of this >>> proposal, and that we also include a magnification point (200%? 400%?) as >>> also part of the requirement: >>> >>> <draft> For the visual presentation of all text, text should naturally >>> re-flow to a minimum of 25 REMs at 200% magnification without horizontal >>> scrolling, with the following exceptions. </draft> >>> >>> ...or something along those lines. By moving away from actual characters >>> (and their "imperfect" unit of measurement), we will likely address most >>> concerns around internationalization, and with a more precise unit of >>> measurement, we will be able to better test (mechanically) compliance to >>> the new SC. (I'd also look to have this be an AA requirement, as opposed to >>> an A, but that is a different discussion...) >>> >>> Thoughts? >>> >>> JF >>> >>> On Wed, Jan 11, 2017 at 8:59 AM, John Foliot <john.foliot@deque.com> >>> wrote: >>> >>>> David wrote: >>>> >>>> > No browser that I know would do this: >>>> > >>>> > "Now is the time for all good men to come to the aid of their >>>> establish- >>>> > ment party for now and forever" >>>> >>>> Erm... https://www.w3.org/TR/css-text/#hyphens-property >>>> and http://caniuse.com/#search=hyphens >>>> (which suggests support in most browsers with the exception of >>>> Android's native browser) >>>> >>>> JF >>>> >>>> On Wed, Jan 11, 2017 at 8:52 AM, David MacDonald <david100@sympatico.ca >>>> > wrote: >>>> >>>>> Perhaps I'm missing something. For example say there is the line >>>>> >>>>> "Now is the time for all good men to come to the aid of their >>>>> establishment party for now and forever" >>>>> >>>>> And lets say that at the end of the word "their" we have a count of 45 >>>>> characters (I didn't count). The browser window is narrowed to 50 >>>>> characters. Then the line will wrap after "their" and it would pass. >>>>> >>>>> "Now is the time for all good men to come to the aid of their (45 >>>>> characters) >>>>> establishment party for now and forever ..." >>>>> >>>>> This would pass because there are 50 or less characters on that line. >>>>> >>>>> No browser that I know would do this: >>>>> >>>>> "Now is the time for all good men to come to the aid of their >>>>> establish- >>>>> ment party for now and forever" >>>>> >>>>> In other words.... most lines will be less than 50 characters if 50 is >>>>> the threshold we decide on. >>>>> >>>>> We have an established precedent in 1.4.8 of using characters to >>>>> measure line length. I think in a dot release we should stick with that, >>>>> unless I'm missing something. >>>>> >>>>> >>>>> >>>>> >>>>> Cheers, >>>>> David MacDonald >>>>> >>>>> >>>>> >>>>> *Can**Adapt* *Solutions Inc.* >>>>> >>>>> Tel: 613.235.4902 <(613)%20235-4902> >>>>> >>>>> LinkedIn >>>>> <http://www.linkedin.com/in/davidmacdonald100> >>>>> >>>>> twitter.com/davidmacd >>>>> >>>>> GitHub <https://github.com/DavidMacDonald> >>>>> >>>>> 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> >>>>> >>>>> On Wed, Jan 11, 2017 at 9:21 AM, Patrick H. Lauke < >>>>> redux@splintered.co.uk> wrote: >>>>> >>>>>> On 11/01/2017 14:12, David MacDonald wrote: >>>>>> >>>>>>> Hi Shwetank >>>>>>> >>>>>>> Can you help us understand how hyphenation works in those languages? >>>>>>> In >>>>>>> English and French, (the languages I speak), the web the page just >>>>>>> wraps >>>>>>> the entire word if it doesn't fit. So there is not generally >>>>>>> hyphenation >>>>>>> for web writing. >>>>>>> >>>>>> >>>>>> Regardless of language, hyphenation will be up to the browser to do >>>>>> (support isn't fantastic / cross-browser just yet), or would require >>>>>> additional JS solutions that forcibly break and hyphenate words (which >>>>>> would likely lead to issues where AT would start to read word fragments >>>>>> rather than full words). So there are potential technical limitations to >>>>>> overcome here as well. >>>>>> >>>>>> P >>>>>> >>>>>> Cheers, >>>>>>> David MacDonald >>>>>>> >>>>>>> >>>>>>> >>>>>>> *Can**Adapt* *Solutions Inc.* >>>>>>> >>>>>>> Tel: 613.235.4902 >>>>>>> >>>>>>> LinkedIn >>>>>>> <http://www.linkedin.com/in/davidmacdonald100> >>>>>>> >>>>>>> twitter.com/davidmacd <http://twitter.com/davidmacd> >>>>>>> >>>>>>> GitHub <https://github.com/DavidMacDonald> >>>>>>> >>>>>>> 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> >>>>>>> >>>>>>> On Wed, Jan 11, 2017 at 8:12 AM, Shwetank Dixit >>>>>>> <shwetank@barrierbreak.com <mailto:shwetank@barrierbreak.com>> >>>>>>> wrote: >>>>>>> >>>>>>> FWIW, I agree with John that character length is not a good >>>>>>> criteria >>>>>>> at all for this purpose, especially from the viewpoint of >>>>>>> non-english languages. I believe the research and guidelines >>>>>>> mentioned in this discussion have not included languages from >>>>>>> scripts apart from the Latin script (please correct me if I’m >>>>>>> wrong) >>>>>>> like Devnagari, Gurkumikhi, or any from the CJK ones for example. >>>>>>> >>>>>>> I am especially concerned about the possibility of significantly >>>>>>> increased ‘hyphenation’ that this could result in (which John >>>>>>> also >>>>>>> mentioned) causing bigger problems from a cognitive perspective. >>>>>>> — >>>>>>> Shwetank >>>>>>> >>>>>>> >>>>>>> On Wednesday, Jan 11, 2017 at 4:32 PM, Michael Pluke >>>>>>>> <Mike.Pluke@castle-consult.com >>>>>>>> <mailto:Mike.Pluke@castle-consult.com>> wrote: >>>>>>>> >>>>>>>> I can see that the choice of characters as the unit of >>>>>>>> measurement >>>>>>>> can result in very different end-results that you get depending >>>>>>>> on >>>>>>>> the chosen font-size and font-face. This may make this unit less >>>>>>>> useful from an LV perspective. ____ >>>>>>>> >>>>>>>> __ __ >>>>>>>> >>>>>>>> However I still think that, from a cognitive perspective, it is >>>>>>>> relevant and important to set a maximum line length in >>>>>>>> characters. >>>>>>>> Long lines with many words/characters are demonstrably hard to >>>>>>>> read for everyone but, most particularly for people with >>>>>>>> dyslexia. The 80 characters in SC 1.4.8 >>>>>>>> <https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-con >>>>>>>> trast-visual-presentation.html> >>>>>>>> will cause significant difficulties for many people with >>>>>>>> dyslexia.____ >>>>>>>> >>>>>>>> __ __ >>>>>>>> >>>>>>>> EA has quoted several research-based sources that offer >>>>>>>> realistic >>>>>>>> line-length proposals. From reading the extract from 'Dyslexia >>>>>>>> in >>>>>>>> the Digital Age' that EA linked-to (http://tinyurl.com/jra7hk3) >>>>>>>> I >>>>>>>> don’t think that it gives very strong evidence that 55 >>>>>>>> characters >>>>>>>> is the only choice. I’m a great fan of the realistic proposals >>>>>>>> that Luz Rello makes (based on her research >>>>>>>> (http://www.luzrello.com/Publications_files/uais2015.pdf >>>>>>>> <http://www.luzrello.com/Publications_files/uais2015.pdf>)) so >>>>>>>> I >>>>>>>> have confidence for specifying line lengths in the 44-66 range >>>>>>>> (although it was non-dyslexic people who benefitted most from 44 >>>>>>>> character columns). The British Dyslexia Style Guide >>>>>>>> http://www.bdadyslexia.org.uk/common/ckeditor/filemanager/us >>>>>>>> erfiles/About_Us/policies/Dyslexia_Style_Guide.pdf >>>>>>>> <http://www.bdadyslexia.org.uk/common/ckeditor/filemanager/u >>>>>>>> serfiles/About_Us/policies/Dyslexia_Style_Guide.pdf> >>>>>>>> recommends that “Lines should not be too long: 60 to70 >>>>>>>> characters.”____ >>>>>>>> >>>>>>>> __ __ >>>>>>>> >>>>>>>> *Conclusion*: Based on all of the above I think that:____ >>>>>>>> >>>>>>>> * To benefit LV users we should avoid having SCs that give a >>>>>>>> line length based on the number of characters;____ >>>>>>>> * To benefit people with dyslexia (and also the general >>>>>>>> population) the 1.4.8-based 80 character maximum in >>>>>>>> proposal #51 <https://github.com/w3c/wcag21/issues/51> >>>>>>>> should >>>>>>>> be reduced to a figure no greater than 70 characters (and >>>>>>>> probably no less than 60).____ >>>>>>>> >>>>>>>> __ __ >>>>>>>> >>>>>>>> Mike____ >>>>>>>> >>>>>>>> __ __ >>>>>>>> >>>>>>>> *From:*John Foliot [mailto:john.foliot@deque.com >>>>>>>> <mailto:john.foliot@deque.com>] >>>>>>>> *Sent:* 10 January 2017 23:56 >>>>>>>> *To:* David MacDonald <david100@sympatico.ca >>>>>>>> <mailto:david100@sympatico.ca>> >>>>>>>> *Cc:* WCAG <w3c-wai-gl@w3.org <mailto:w3c-wai-gl@w3.org>> >>>>>>>> *Subject:* Re: Length of line____ >>>>>>>> >>>>>>>> __ __ >>>>>>>> >>>>>>>> TL;DR - Using 'character' as a unit of measurement is extremely >>>>>>>> problematic, and I do not support it's use here. ____ >>>>>>>> >>>>>>>> __ __ >>>>>>>> >>>>>>>> **************____ >>>>>>>> >>>>>>>> __ __ >>>>>>>> >>>>>>>> Some thoughts after today's call.____ >>>>>>>> >>>>>>>> __ __ >>>>>>>> >>>>>>>> I personally have significant concerns over prescribing a fixed >>>>>>>> number of characters, especially such a low number, as a unit of >>>>>>>> measurement. ____ >>>>>>>> >>>>>>>> __ __ >>>>>>>> >>>>>>>> *Internationalization:*____ >>>>>>>> >>>>>>>> When we factor in both Internationalization and languages other >>>>>>>> than English, we will quickly arrive at a point where the number >>>>>>>> 25 is smaller than numerous words in different languages >>>>>>>> (https://en.wikipedia.org/wiki/Longest_words >>>>>>>> <https://en.wikipedia.org/wiki/Longest_words>), which will then >>>>>>>> require word hyphenization (most probably supplied by the >>>>>>>> content >>>>>>>> author, until such time as AI can do that job seamlessly). This >>>>>>>> then suggests to me that we will start to see 'forced' >>>>>>>> line-breaks >>>>>>>> again (using the presentational <br>), which could have a >>>>>>>> significant impact on screen flow in RWD (Responsive) layouts >>>>>>>> (i.e. the cure being worse the the symptom).____ >>>>>>>> >>>>>>>> __ __ >>>>>>>> >>>>>>>> __ __ >>>>>>>> >>>>>>>> *Font-size and font-face choices:*____ >>>>>>>> >>>>>>>> Equally, as mentioned on the call, another factor in measuring >>>>>>>> this, related to horizontal scrolling, is font-size. For those >>>>>>>> of >>>>>>>> you using HTML-rich mail clients, and using a 25 character-count >>>>>>>> example taken from >>>>>>>> http://www.litscape.com/words/length/25_letters/25_letter_wo >>>>>>>> rds.html >>>>>>>> <http://www.litscape.com/words/length/25_letters/25_letter_w >>>>>>>> ords.html>:____ >>>>>>>> >>>>>>>> __ __ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> electroencephalographical____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> (Gmail's____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> '____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> S____ >>>>>>>> >>>>>>>> mall' sizing)____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> electroencephalographical (Gmail's____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> 'Normal' sizing)____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> electroencephalographical (Gmail's____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> 'Large' sizing)____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> electroencephalographical (Gmail's____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> 'Huge' sizing)____ >>>>>>>> >>>>>>>> __ __ >>>>>>>> >>>>>>>> Q: How do we test for "success" here? Even the final line above >>>>>>>> (Gmail's "Huge" font-size) could introduce horizontal scrolling >>>>>>>> at >>>>>>>> some level of magnification on some devices, yet at 25 >>>>>>>> characters >>>>>>>> "meets" the current wording of the proposed SC. ____ >>>>>>>> >>>>>>>> __ __ >>>>>>>> >>>>>>>> Additionally, different font-faces will have different >>>>>>>> font-width >>>>>>>> characteristics, depending on the font-face chosen. For >>>>>>>> example:____ >>>>>>>> >>>>>>>> __ __ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> electroencephalographical (Gmail 'sans-serif', size >>>>>>>> 'normal')____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> electroencephalographical (Gmail 'Verdana', size >>>>>>>> 'normal') ____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> electroencephalographical (Gmail 'Wide', size >>>>>>>> 'normal')____ >>>>>>>> >>>>>>>> __ __ >>>>>>>> >>>>>>>> ...once again, depending on the font-face choice we have 3 >>>>>>>> different line-lengths, and so I question the overall choice of >>>>>>>> "character" as a unit of measurement here.____ >>>>>>>> >>>>>>>> __ __ >>>>>>>> >>>>>>>> __ __ >>>>>>>> >>>>>>>> *How to 'Succeed'/Author push-back:*____ >>>>>>>> >>>>>>>> The current proposed language for this SC reads:____ >>>>>>>> >>>>>>>> For the visual presentation of all text, a mechanism is >>>>>>>> available such that line length is user adjustable, to 25 >>>>>>>> characters, with no two-dimensional scrolling required, and >>>>>>>> with the following exceptions.____ >>>>>>>> >>>>>>>> __ __ >>>>>>>> >>>>>>>> However, it is unclear what a page author can or should do to >>>>>>>> meet >>>>>>>> this requirement____ >>>>>>>> >>>>>>>> , as it very much feels like a User-Agent requirement as much >>>>>>>> as >>>>>>>> anything else. For SC 1.4.8, one technique is ____ >>>>>>>> >>>>>>>> G204 >>>>>>>> <https://www.w3.org/WAI/GL/2016/WD-WCAG20-TECHS-20160105/G204>: >>>>>>>> /Not interfering with the user agent's reflow of text as the >>>>>>>> viewing window is narrowed/____ >>>>>>>> >>>>>>>> /, /which seems to me to at least address the larger issue >>>>>>>> (avoid horizontal scrolling) without prescribing a specific >>>>>>>> line-length.____ >>>>>>>> >>>>>>>> __ __ >>>>>>>> >>>>>>>> Finally, the current Success Criteria that requires an 80 >>>>>>>> character line-length (____ >>>>>>>> >>>>>>>> SC 1.4.8 >>>>>>>> <https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-con >>>>>>>> trast-visual-presentation.html>) >>>>>>>> is a AAA Success Criteria requirement, and yet this new proposed >>>>>>>> SC is at level A, at roughly 1/3 the 80-char limit. ____ >>>>>>>> >>>>>>>> Sadly (but not totally unreasonably) ____ >>>>>>>> >>>>>>>> I suspect that we will get significant push-back at level A____ >>>>>>>> >>>>>>>> .____ >>>>>>>> >>>>>>>> __ __ >>>>>>>> >>>>>>>> JF____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> __ __ >>>>>>>> >>>>>>>> On Tue, Jan 10, 2017 at 3:31 PM, David MacDonald >>>>>>>> <david100@sympatico.ca <mailto:david100@sympatico.ca>> >>>>>>>> wrote:____ >>>>>>>> >>>>>>>> I'm the manager of Issue #57 line length. >>>>>>>> >>>>>>>> https://github.com/w3c/wcag21/issues/57 >>>>>>>> <https://github.com/w3c/wcag21/issues/57> >>>>>>>> >>>>>>>> I was asked to explain why 25 characters was chosen as the >>>>>>>> threshold. I deferred to the LVTF____ >>>>>>>> >>>>>>>> since I did not write that requirement____ >>>>>>>> >>>>>>>> . One point that was mentioned was that 25 characters is >>>>>>>> about >>>>>>>> the width of most news article columns. >>>>>>>> >>>>>>>> I did a survey of several top news sites on the web and >>>>>>>> measured the length of characters when text size is 100% >>>>>>>> (no zoom) >>>>>>>> >>>>>>>> -CNN 74____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> characters without counting spaces 87 with spaces. could >>>>>>>> narrow to 35 (w/ spaces) in Responsive >>>>>>>> -NBC 61 no spaces 73 with spaces, could narrow to 39 (w/ >>>>>>>> spaces) >>>>>>>> -ABC NEWS 81 no spaces 92 Spaces, could narrow to 43 in >>>>>>>> responsive >>>>>>>> -FoxNews 67 no space 79 spaces could narrow to 45 in >>>>>>>> responsive >>>>>>>> -Le Droit french 74 no space, 86 with spaces, no responsive >>>>>>>> -Google News 73 No Spaces 87 with spaces could narrow to 44 >>>>>>>> in >>>>>>>> responsive >>>>>>>> - Huff post French 67 no spaces 79 with spaces no >>>>>>>> responsive____ >>>>>>>> >>>>>>>> N____ >>>>>>>> >>>>>>>> one of these sites passed the new SC proposal of 25 >>>>>>>> characters. They all went to horizontal scroll when window >>>>>>>> was >>>>>>>> narrowed less than those ____ >>>>>>>> >>>>>>>> minimum character ____ >>>>>>>> >>>>>>>> widths shown above.____ >>>>>>>> >>>>>>>> Do we____ >>>>>>>> >>>>>>>> want to make the minimum a little wider, say 45 or 50 >>>>>>>> characters. >>>>>>>> >>>>>>>> For reference, the following is about 25 characters:____ >>>>>>>> >>>>>>>> >>>>>>>> "This test assesses basic"____ >>>>>>>> >>>>>>>> __ __ >>>>>>>> >>>>>>>> __ __ >>>>>>>> >>>>>>>> Cheers, >>>>>>>> David MacDonald____ >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> *Can**Adapt* *Solutions Inc.*____ >>>>>>>> >>>>>>>> Tel: 613.235.4902 <tel:(613)%20235-4902>____ >>>>>>>> >>>>>>>> LinkedIn >>>>>>>> <http://www.linkedin.com/in/davidmacdonald100>____ >>>>>>>> >>>>>>>> twitter.com/davidmacd <http://twitter.com/davidmacd>____ >>>>>>>> >>>>>>>> GitHub <https://github.com/DavidMacDonald>____ >>>>>>>> >>>>>>>> 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/disc >>>>>>>> laimer.html>____ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ____ >>>>>>>> >>>>>>>> __ __ >>>>>>>> >>>>>>>> -- ____ >>>>>>>> >>>>>>>> John Foliot____ >>>>>>>> >>>>>>>> Principal Accessibility Strategist____ >>>>>>>> >>>>>>>> Deque Systems Inc.____ >>>>>>>> >>>>>>>> john.foliot@deque.com <mailto:john.foliot@deque.com>____ >>>>>>>> >>>>>>>> __ __ >>>>>>>> >>>>>>>> Advancing the mission of digital accessibility and inclusion____ >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> Patrick H. Lauke >>>>>> >>>>>> www.splintered.co.uk | https://github.com/patrickhlauke >>>>>> http://flickr.com/photos/redux/ | http://redux.deviantart.com >>>>>> twitter: @patrick_h_lauke | skype: patrick_h_lauke >>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> John Foliot >>>> Principal Accessibility Strategist >>>> Deque Systems Inc. >>>> john.foliot@deque.com >>>> >>>> Advancing the mission of digital accessibility and inclusion >>>> >>> >>> >>> >>> -- >>> John Foliot >>> Principal Accessibility Strategist >>> Deque Systems Inc. >>> john.foliot@deque.com >>> >>> Advancing the mission of digital accessibility and inclusion >>> >> >> > > > -- > John Foliot > Principal Accessibility Strategist > Deque Systems Inc. > john.foliot@deque.com > > Advancing the mission of digital accessibility and inclusion >
Received on Wednesday, 11 January 2017 18:22:12 UTC