Re: Length of line

> 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/disclaimer.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 17:28:52 UTC