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. 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 CanAdapt Solutions Inc.Tel:  613.235.4902LinkedIn 
twitter.com/davidmacdGitHubwww.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

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