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: Jonathan Cohn
Date: Jan 4, 2018 11:49AM

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
>
> > > > >