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 3:53PM

Anybody got a list of crawling accessibility testing tools that *do* let
you run tests at different viewport sizes? Our current tool lacks that
feature, which is really absurd, at this point, I think.

On Fri, Jan 5, 2018 at 5:43 PM, Jonathan Avila < <EMAIL REMOVED> >
wrote:

> > The issue of automated tests is interesting. I don't find automated
> tools particularly useful so my experience of them is relatively limited,
> but I was surprised to find that SortSite gave exactly the same results on
> a recent project regardless of the viewport dimensions. For instance, it
> reported non-compliances that only occurred in the mobile layout even
> though the desktop layout was being displayed.
>
> Our AMP platform allows you to specify some different devices when
> crawling a site so the headless browser can use different viewport widths
> and thus perform automated spider testing at several different
> breakpoints. The browser based automated tool Access Assistant tests
> currently what is visible in the browser -- so it will test at the
> breakpoint displayed.
>
> > I had never thought about this before and I'm not sure if this is a
> serious fault or not. I also don't know if other tools do the same. One
> definite downside is that it reports duplicate IDs even if only one of the
> two elements is displayed at any time (the other being hidden with
> display:none).
>
> Duplicate ids even when hidden are something that need to be checked for.
> That is because aria-labelledby and aria-describedby can reference content
> that is display:none.
>
> Jonathan
>
> Jonathan Avila
> Chief Accessibility Officer
> Level Access, inc. (formerly SSB BART Group, inc.)
> (703) 637-8957
> <EMAIL REMOVED>
> Visit us online: Website | Twitter | Facebook | LinkedIn | Blog
> Looking to boost your accessibility knowledge? Check out our free webinars!
>
> The information contained in this transmission may be attorney privileged
> and/or confidential information intended for the use of the individual or
> entity named above. If the reader of this message is not the intended
> recipient, you are hereby notified that any use, dissemination,
> distribution or copying of this communication is strictly prohibited.
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On
> Behalf Of Steve Green
> Sent: Friday, January 5, 2018 3:10 PM
> To: WebAIM Discussion List < <EMAIL REMOVED> >
> Subject: Re: [WebAIM] Making mobile view available to all as way of
> constraining a11y testing costs
>
> That's exactly what we do on every project and it isn't particularly
> onerous at all. When I am pricing testing projects I usually reckon that a
> responsive design takes about 25% longer than a non-responsive one.
>
> The whole point of investigating what changes at each breakpoint is to
> avoid having to repeat every test. Once you understand the code you can
> easily predict which success criteria are affected. Of course you have to
> be able to read and understand all the HTML, CSS and JavaScript in order to
> do that, but anyone who is doing accessibility testing should be able to.
>
> The issue of automated tests is interesting. I don't find automated tools
> particularly useful so my experience of them is relatively limited, but I
> was surprised to find that SortSite gave exactly the same results on a
> recent project regardless of the viewport dimensions. For instance, it
> reported non-compliances that only occurred in the mobile layout even
> though the desktop layout was being displayed.
>
> I had never thought about this before and I'm not sure if this is a
> serious fault or not. I also don't know if other tools do the same. One
> definite downside is that it reports duplicate IDs even if only one of the
> two elements is displayed at any time (the other being hidden with
> display:none).
>
> Steve
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On
> Behalf Of Robert Fentress
> Sent: 05 January 2018 19:09
> To: WebAIM Discussion List < <EMAIL REMOVED> >
> Subject: Re: [WebAIM] Making mobile view available to all as way of
> constraining a11y testing costs
>
> 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
> > > > > > archives at http://webaim.org/discussion/archives
> > > >
>
>
>
> --
> 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>
> > > at http://webaim.org/discussion/archives
> > > > at http://webaim.org/discussion/archives
> > > > > >



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