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: Steve Green
Date: Jan 4, 2018 12:14PM

The approach that we use exactly mirrors Patrick's advice. Find out where all the breakpoints are - don't just check where you expect them to be. Find out what changes and how. Then make an informed decision on what to test at each breakpoint.

If you adopt a more simplistic heuristic such as "just test the end-points" you run the risk of missing some issues. Testing is always a balance between time (and hence cost) and thoroughness, so in some contexts a simple heuristic may be the most appropriate choice.

The important thing is to understand the risks of such an approach and to ensure that your stakeholders are happy with those risks. Let them make the decision because it's their responsibility to assign the necessary resources to achieve the outcomes they require. Don't hide your shortcuts just to please them!

FWIW, I recently tested a website where the mobile content was substantially different from the desktop layout. Not only was the content on each page reduced compared with the desktop layout (which is not unreasonable if done well), but you could not access a lot of the pages from the mobile layout. It was absolutely bonkers!

Not only could you not find pages that you knew existed, but if you reduced the window width on a desktop browser you suddenly couldn't access pages you had viewed a few minutes earlier in the same browser! If you reduced the width of a page that could not be accessed in the mobile layout, the appearance would screw up because the "narrow layout" styles had not been specified for some elements. Obviously I can't name the giant Indian outsource IT company that built this monstrosity.

Steve Green
Managing Director
Test Partners Ltd


-----Original Message-----
From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf Of Jonathan Cohn
Sent: 04 January 2018 18:49
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] Making mobile view available to all as way of constraining a11y testing costs

Wow, I have to use my imagination here to think that there could be that significant a change at different breakpoints. I would find it confusing personally, if a specific web page looked significantly different on my spouses 1024x2000 display versus my 4K display. Certainly, I have heard blind IOS users complain about left side panels on iPads as being confusing since they don't exist on iPhones. Maybe I am overthinking Pat's argument and he is sayng it depends. So if we have four potential layouts and item a is hidden in 1 - 3 in exactly the same manner than it should only need to be tested in 1 and 4 layouts. So, unless a menu transitions from a hamburger to a top level menu to a left side menu couldn't all possibilities be handled by testing the end-points?







On 4 January 2018 at 11:22, Patrick H. Lauke < <EMAIL REMOVED> > wrote:

> 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
>
> > > archives at http://webaim.org/discussion/archives
> >