Re: Very large print = refresh-able braille

David wrote:
> The subject of the thread is "Very large print = refresh-able braille".

I took it less literally than that, I think Wayne was using that as a metaphor.

James wrote:
> Just to point out that a bookmarklet can work as a proof of concept but cannot work on production sites for a number of reasons – the primary one being content security policies.

Yep, I was reading around, and it looks like it would work from an extension, but not when you load in an external script (which is kinda the point of CSP!). Github is a good example, that has a strict CSP and blocks the bookmarklets.
The intent is to provide a proof of concept, and potentially rules that can be included in an extension, and possibly a simple test tool.
Something to get past the chicken/egg problem we have at the moment.

Cheers,

-Alastair


From: James Nurthen <james.nurthen@oracle.com>
Date: Wednesday, 29 March 2017 at 21:31
To: 'David MacDonald' <david100@sympatico.ca>, 'Joshue O Connor' <josh@interaccess.ie>
Cc: Alastair Campbell <acampbell@nomensa.com>, 'Wayne Dick' <wayneedick@gmail.com>, WCAG <w3c-wai-gl@w3.org>
Subject: RE: Very large print = refresh-able braille

Just to point out that a bookmarklet can work as a proof of concept but cannot work on production sites for a number of reasons – the primary one being content security policies.

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



CanAdapt 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, Mar 29, 2017 at 1:06 PM, Joshue O Connor <josh@interaccess.ie<mailto: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<mailto:david100@sympatico.ca>>
Date: 29/03/2017 17:25 (GMT+00:00)
To: Alastair Campbell <acampbell@nomensa.com<mailto:acampbell@nomensa.com>>
Cc: Wayne Dick <wayneedick@gmail.com<mailto:wayneedick@gmail.com>>, GLWAI Guidelines WG org <w3c-wai-gl@w3.org<mailto: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.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>

On Wed, Mar 29, 2017 at 4:37 AM, Alastair Campbell <acampbell@nomensa.com<mailto: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