WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Making mobile view available to all as way of constraining a11y testing costs

for

From: Patrick H. Lauke
Date: Jan 4, 2018 9:22AM

On 04/01/2018 16:06, Robert Fentress wrote:
> Hello, all.
>
> I've been thinking about how time consuming it is to fully test the
> accessibility of every breakpoint on every page and am looking for ways to
> economize. I wonder if it might be an acceptable alternative, given
> resource constraints, to just fully test the largest desktop breakpoint and
> the smallest mobile breakpoint.

I'd say it makes more sense to understand what actually happens/changes
at each breakpoint. You don't necessarily have to test each breakpoint
as if it were a completely isolated new page instance, in most cases.

If changes are purely stylistic, you can test once (at whatever viewport
size has all the features etc) and then just check that the differences
in styling don't cause any new issues (for instance, if elements are
suppressed from being displayed in smaller viewports, check that they're
removed correctly and not just visually hidden but still
focusable/present in the reading order; if a layout is
changed/linearized, check that the reading and focus order are still
correct).

If changes also involve changes in functionality (e.g. a top navigation
turns into a hamburger menu), hone in on testing the top navigation AND
the hamburger menu, and ensure that both are accessible and appropriate.

> If this strategy were adopted, then an
> option would be provided to users to automatically apply the styles
> associated with the small breakpoint in any context, maybe by clicking on
> an icon of a finger touching a mobile screen.

On desktop, users can trigger different viewports by using full-page
zoom (assuming the site uses responsive techniques).

On mobile/tablet devices yes, users can't trigger different breakpoints,
and would need some kind of control/switch.

> This affordance would likely
> be useful to any number of users who might prefer that presentation, such
> as those using touch on a regular-sized laptop with a large viewport, and
> it would ensure that at least one fully-tested view was always available to
> users. This would, of course, assume that developers and content authors
> received appropriate training on developing accessibly, so that, hopefully,
> the other breakpoints would still be accessible. This strategy is just a
> way of dealing with the reality that, in an auditing context, there are
> limited resources available for testing, and a seemingly growing number of
> breakpoints as the largest possible viewport size increases. What do you
> think?

Generally, this falls in line with a discussion that was had ages ago in
the run up to WCAG 2.1 authoring, and goes a little something like this
(I'll paraphrase/editorialise from memory):

- if a page has different presentations/functionalities based on factors
that a user can't easily change (like viewport dimensions of their
UA/device), then you can't rely on only one of them being "accessible"
and the other ones not, as it's outside of the user's ability to change
between them. All forms of the page still form part of that single page,
in this case, and every state needs to be tested/accounted for.

- if you DO provide an explicit switch/setting to change between them
that doesn't rely just on things like viewport, you're essentially
creating two separate versions of the page, and having only one of them
accessible is also fine per WCAG.

Generally, I'd still say it makes more sense to test all possible states
of a page. Yes, auditing takes longer, but that's when this needs to be
made clear to clients (assuming we're talking auditing service for a
client here). If a site is responsive and has changes in layout and/or
functionality at different breakpoints, you'd want to tell the client
that for each significant breakpoint you're going to spend more time
testing (add a multiplier - worst case, if a page changes completely
between breakpoints, a factor of 2 is added to time/cost estimates).

If this is about auditing time internally within your own organisation,
I'd say again it needs to simply be made clear to the
higher-ups/management. Each new breakpoint with significant changes
requires separate time to test. That's simply the way it is, and trying
to find cheaper/quicker ways around it is not really sustainable or in
the best interest of the users.

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke