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

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
>
>
>
>
>
>
>