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: Robert Fentress
Date: Jan 5, 2018 12:08PM

Thanks for the feedback.

It is hard to know where the issues will show up at different breakpoints,
unless you actually change the viewport and rerun all the automated and
manual/heuristic checks, and that can be quite time-consuming. You can
spitball it and say, "Well, it looks like not much has changed, so I only
really need to look at this bit," but then you can't *really* say you've
verified that the view is accessible. This may be fine, if such a
qualification is made in any report, but, if resource constraints require
you to be more thrifty in your testing, having that backup of *knowing*
that at least one view that is available to the user has been *fully*
tested for accessibility can allow you to say something more definitive
about whether a page is conformant. I think you expressed what I was going
for with your comment, "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."

On Thu, Jan 4, 2018 at 11:22 AM, 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
> > > > >



--
Rob Fentress
Senior Accessibility Solutions Designer
Assistive Technologies at Virginia Tech
Electronic Business Card (vCard)
<http://search.vt.edu/search/person.vcf?person54847>
LinkedIn Profile
<https://www.linkedin.com/in/rob-fentress-aa0b609?trk=profile-badge>