Re: Very large print = refresh-able braille

+1

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 Tue, Mar 28, 2017 at 5:09 AM, Alastair Campbell <acampbell@nomensa.com>
wrote:

> Wayne wrote:
>
> > Large print with word wrapping is as necessary as refresh-able braille
> for the same reason.  Why do well meaning accessibility experts claim that
> well formatted large print is just too hard to provide?
>
>
>
> I’ll put on the devil’s advocate hat for a moment: Degree of effort
> required.
>
>
>
> To enable (or rather not disrupt) a screenreader with whatever physical
> output it provides, you use standard HTML elements and pre-defined
> attributes. You can create whatever layout and design you would like and
> provide everything a screenreader user needs.
>
>
>
> I checked in with our (very accessibility aware) front-end developers, and
> the proportion of their development time is generally 10% HTML, 30% CSS,
> 50% JS and 10% Other (task runners, env issues etc). The time spent on
> choosing the right HTML elements is a tiny proportion of the overall dev
> time, probably around 1%. If you’re doing some complex ARIA widgets that
> will increase, but again it is a small increase over the effort you’d have
> to put in to make the widget work in the first place (when building in from
> the start).
>
>
>
> The time spent getting the layouts and presentation to work at all is much
> greater (30%), and if you multiply that effort (e.g. provide another
> layout) you are multiplying the development and testing time required. Any
> increase to visual browser-based testing also increases the ongoing cost of
> maintenance and testing changes compared to the fairly static HTML
> foundation (or putting ramps in for wheelchair access).
>
>
>
> If it is not done as a separate layout, it might reduce the optimal
> information density for people without low vision, and reduce the site’s
> income (e.g. how many items are shown in search results for an ecommerce
> site).
>
>
>
> That is why I highlighted layout changes as significantly increasing the
> level of effort required [1]. From a low vision point of view:
>
>
>
> 1.   Resize in the browser is almost ‘free’ [2] if the site is responsive.
>
> 2.   Overriding text-styles doesn’t (well, shouldn’t) impact layout, so
> avoiding certain techniques should not increase the cost/complexity for
> developers.
>
> 3.   Overriding the layout (linearization) is also a matter of avoiding
> certain techniques that get in the way, but the developer doesn’t have to
> provide a linearised layout and a mechanism to choose it, the user brings
> that to the table.
>
> 4.   Supplying alternative layout(s) and a mechanism to choose it is a
> massive increase in effort and complexity that will also add cost for every
> future update.
>
>
>
> That’s why I’ve tried to steer the LVTF SCs away from impacting layout in
> ways that hugely increase the effort required.
>
>
>
> Cheers,
>
>
>
> -Alastair
>
>
>
> 1] https://alastairc.ac/2017/02/four-levels-of-accessibility-
> customisation/
>
> 2] There can be issues from portrait/landscape that need testing & fixing
> such as sticky headers, but it is straightforward to solve.
>