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 5, 2018 4:03PM

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

That's a very good point. In practice, where the IDs are intentionally duplicated we invariably find that the contents of the elements are identical. Would you still regard that as a non-compliance? I don't think I would. That said, I still encourage clients to change one of the IDs.

What is the pricing for AMP? I suspect it costs a bit more than SortSite and the license is probably tied to a specific domain, which is no good for us.

Steve

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

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