Re: Very large print = refresh-able braille

>I think the core of this is the ideal that web content is fit for purpose
for Low Vision users, out of the box, and without the need for AT.

The subject of the thread is "Very large print = refresh-able braille". The
is an SC proposal on the table called "Printing" that requires the ability
to print 200% ... I thought that was what the thread was about and what I'm
commenting on. https://github.com/w3c/wcag21/issues/76

Regarding the Linearization SC https://github.com/w3c/wcag21/issues/58

Of which I am the manager, there are compelling reasons to make it work as
an SC. The question remains for non responsive sites, whether Alastair can
create a bookmarklet or plugin that works on ALL sites, in time for
finalization of the SC. We also have to figure out what to do about PDFs
and complex applications, which we need to manage with exceptions, perhaps
the "essential exception is enough perhaps we need more. Waiting for public
comments.

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, Mar 29, 2017 at 1:06 PM, Joshue O Connor <josh@interaccess.ie>
wrote:

> I think the core of this is the ideal that web content is fit for purpose
> for Low Vision users, out of the box, and without the need for AT. That's
> what I'm hearing and I think Wayne has presented compelling arguments for
> this.
>
> Thanks
>
> Josh
>
> InterAccess - Accessible UX
>
> -------- Original message --------
> From: David MacDonald <david100@sympatico.ca>
> Date: 29/03/2017 17:25 (GMT+00:00)
> To: Alastair Campbell <acampbell@nomensa.com>
> Cc: Wayne Dick <wayneedick@gmail.com>, GLWAI Guidelines WG org <
> w3c-wai-gl@w3.org>
> Subject: Re: Very large print = refresh-able braille
>
> There is no requirement in WCAG for authors to provide braille... an
> engine in the AT converts the text to speech of the AT output to their
> Braille devices.   http://doccenter.freedomscientific.com/
> doccenter/doccenter/rs11f929e9c511/2012-04-12_teachersandtrainers-l4/02_
> jawsandbraille.htm
>
> Once something is printed it is not at an HTTP address and under the
> current definition of web content is out of scope.
> https://www.w3.org/TR/WCAG20/#webpagedef
>
> Printing large print is important, but it seems out of scope, a user agent
> issue.
>
>
>
>
> 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, Mar 29, 2017 at 4:37 AM, Alastair Campbell <acampbell@nomensa.com>
> wrote:
>
>> Wayne wrote:
>> > If authors design with the possibility of linearization in mind then
>> the browser facilities should do the job. Did I miss something?
>>
>> Perhaps it is terminology, but ‘providing large print’ implies it is
>> something authors have to do, like people providing paper things providing
>> a large-print paper copy. If the developer has to provide an alternative
>> interface, that’s a big thing to do (in the region of adding 20-40% to
>> development & testing cost). If they avoid some techniques to enable
>> user-driven linearization, that is a lot more reasonable.
>>
>> Linearization is, as you say [1], one implementation. The conceptual
>> difference between an override approach (linearization) and the approach
>> you described in #174, is effort & standardised approach.
>>
>> If the IDE example is to reflow properly, it has to be designed to do so.
>> You can’t just override and say “all block elements take 100% in 1 column”,
>> as lots of things would simply break. Either the developer would need to
>> provide an alternative layout, or there would need to be a standard to
>> identify the “content units” you outlined.
>>
>> Without a standard to say what a content unit is, even an ad-hoc one such
>> as using some aria-regions as a proxy, that type of customisation isn’t
>> possible.
>>
>> Therefore, I suggest we try and thread the needle on linearization for
>> 2.1, and support the COGA semantics / personalisation effort for the longer
>> term solution. I hope some of that gets into 2.1, but it isn’t clear that
>> (all of) the semantics standard will be ready in that timeline.
>>
>>
>> > The central fact is this if refreshable braille is necessary and
>> important enough to require developer pre-planning then so is large  print,
>> because they serve the same function. One that enlargement without word
>> wrapping cannot satisfy.
>>
>> Not really, no one is arguing with the user-need. The “central fact” is
>> that providing support to a screenreader (and therefore refreshable
>> braille) is a reasonable thing to require of companies because it can be
>> done without doubling your development costs. Our aim should be to also
>> make digital ‘large print’ a reasonable thing to do.
>>
>> Kind regards,
>>
>> -Alastair
>>
>> 1] https://github.com/w3c/wcag21/issues/174
>>
>>
>>
>>
>>
>>
>>
>