Re: Very large print = refresh-able braille

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.