E-mail List Archives
Thread: Making mobile view available to all as way of constraining a11y testing costs
Number of posts in this thread: 22 (In chronological order)
From: Robert Fentress
Date: Thu, Jan 04 2018 9:06AM
Subject: Making mobile view available to all as way of constraining a11y testing costs
No previous message | Next message →
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. 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. 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?
Best,
Rob
--
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>
From: Patrick H. Lauke
Date: Thu, Jan 04 2018 9:22AM
Subject: Re: Making mobile view available to all as way of constraining a11y testing costs
← Previous message | Next message →
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
From: Jonathan Cohn
Date: Thu, Jan 04 2018 11:49AM
Subject: Re: Making mobile view available to all as way of constraining a11y testing costs
← Previous message | Next message →
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 ADDRESS 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
>
> > > > >
From: Steve Green
Date: Thu, Jan 04 2018 12:14PM
Subject: Re: Making mobile view available to all as way of constraining a11y testing costs
← Previous message | Next message →
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 ADDRESS REMOVED = ] On Behalf Of Jonathan Cohn
Sent: 04 January 2018 18:49
To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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
> >
From: Jonathan Avila
Date: Thu, Jan 04 2018 4:05PM
Subject: Re: Making mobile view available to all as way of constraining a11y testing costs
← Previous message | Next message →
> 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?
Because I use low resolution on desktop or some browser zoom I find myself almost always entering mobile breakpoints on my desktop . In my experience page zoom not only changes the viewport with but also the scale factor. So the text size of sites is different at a width of 533 then it would be by zooming to say 150% that gets me to 533 (number made up) but also has a scale factor of 1.5. Thus there is a larger opportunity for non-fluid responsive sites to have issues such as text that is cutoff or overflows over other text or text over a different background without sufficient contrast. A truly fluid site would not have these issues but in my experience most sites really aren't truly fluid but instead are a series of breakpoints.
Jonathan
Jonathan Avila
Chief Accessibility Officer
Level Access, inc. (formerly SSB BART Group, inc.)
(703) 637-8957
= EMAIL ADDRESS 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 ADDRESS REMOVED = ] On Behalf Of Robert Fentress
Sent: Thursday, January 4, 2018 11:06 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: [WebAIM] Making mobile view available to all as way of constraining a11y testing costs
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. 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. 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?
Best,
Rob
--
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>
From: Patrick H. Lauke
Date: Thu, Jan 04 2018 4:18PM
Subject: Re: Making mobile view available to all as way of constraining a11y testing costs
← Previous message | Next message →
On 04/01/2018 23:05, Jonathan Avila wrote:
>> 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?
>
> Because I use low resolution on desktop or some browser zoom I find myself almost always entering mobile breakpoints on my desktop . In my experience page zoom not only changes the viewport with but also the scale factor. So the text size of sites is different at a width of 533 then it would be by zooming to say 150% that gets me to 533 (number made up) but also has a scale factor of 1.5.
I'm sure we've had this conversation many times before, but: using page
zoom effectively changes how many physical/screen pixels make up a CSS
pixel. So yes, full-page zoom will result in everything being bigger by
that factor, and the reported viewport width being smaller by that same
factor.
> Thus there is a larger opportunity for non-fluid responsive sites to have issues such as text that is cutoff or overflows over other text or text over a different background without sufficient contrast.
Do you have actual examples where this happens? Because it's not really
a given that responsive sites would cause more or less
cutoffs/overflowing, since every measure (be it a measure set in pixels,
or ems, or whatever) is scaled exactly the same way.
> A truly fluid site would not have these issues but in my experience most sites really aren't truly fluid but instead are a series of breakpoints.
Do you have actual examples of a "truly fluid" site versus a "non-fluid
responsive" site?
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
From: Robert Fentress
Date: Fri, Jan 05 2018 12:08PM
Subject: Re: Making mobile view available to all as way of constraining a11y testing costs
← Previous message | Next message →
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 ADDRESS 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>
From: Steve Green
Date: Fri, Jan 05 2018 1:09PM
Subject: Re: Making mobile view available to all as way of constraining a11y testing costs
← Previous message | Next message →
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 ADDRESS REMOVED = ] On Behalf Of Robert Fentress
Sent: 05 January 2018 19:09
To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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>
From: Patrick H. Lauke
Date: Fri, Jan 05 2018 2:08PM
Subject: Re: Making mobile view available to all as way of constraining a11y testing costs
← Previous message | Next message →
On 05/01/2018 20:09, Steve Green 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.
FWIW that's one of my ongoing gripes about the Lighthouse-based "Audit"
available in current Chrome DevTools (which uses aXe), as that runs all
audits (including the accessibility one) only in mobile viewport size.
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
From: Jonathan Avila
Date: Fri, Jan 05 2018 3:43PM
Subject: Re: Making mobile view available to all as way of constraining a11y testing costs
← Previous message | Next message →
> 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 ADDRESS 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 ADDRESS REMOVED = ] On Behalf Of Steve Green
Sent: Friday, January 5, 2018 3:10 PM
To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED = ] On Behalf Of Robert Fentress
Sent: 05 January 2018 19:09
To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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>
From: Robert Fentress
Date: Fri, Jan 05 2018 3:50PM
Subject: Re: Making mobile view available to all as way of constraining a11y testing costs
← Previous message | Next message →
But aXe, itself, does work, I believe, at testing the page at whatever
viewport size you are currently using.
On Fri, Jan 5, 2018 at 4:08 PM, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = >
wrote:
> On 05/01/2018 20:09, Steve Green 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.
>>
>
> FWIW that's one of my ongoing gripes about the Lighthouse-based "Audit"
> available in current Chrome DevTools (which uses aXe), as that runs all
> audits (including the accessibility one) only in mobile viewport size.
>
>
> 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>
From: Robert Fentress
Date: Fri, Jan 05 2018 3:53PM
Subject: Re: Making mobile view available to all as way of constraining a11y testing costs
← Previous message | Next message →
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 ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = ] On
> Behalf Of Steve Green
> Sent: Friday, January 5, 2018 3:10 PM
> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED = ] On
> Behalf Of Robert Fentress
> Sent: 05 January 2018 19:09
> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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>
From: Steve Green
Date: Fri, Jan 05 2018 4:03PM
Subject: Re: Making mobile view available to all as way of constraining a11y testing costs
← Previous message | Next message →
"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 ADDRESS REMOVED = ] On Behalf Of Jonathan Avila
Sent: 05 January 2018 22:44
To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = ] On Behalf Of Steve Green
Sent: Friday, January 5, 2018 3:10 PM
To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED = ] On Behalf Of Robert Fentress
Sent: 05 January 2018 19:09
To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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>
From: Jonathan Avila
Date: Fri, Jan 05 2018 4:37PM
Subject: Re: Making mobile view available to all as way of constraining a11y testing costs
← Previous message | Next message →
> [Patrick wrote] Do you have actual examples where this happens?
This Hampton Inn site is not responsive but provides an example of when you zoom in and scrollbars appear text is pushed off to the right. When you scroll over to read the text the white text in the banner links can't be read because it no longer appears on a blue background but on a white background. In this case the container is a fixed width. I haven't diagnosed specifically what is happening but I'd imagine that this could happen to a responsive site that was not truly fluid. A responsive site can simply be a set of breakpoints on fixed width elements.
http://hamptoninn3.hilton.com/
I haven't reviewed the site for accessibility -- but just happened to see this particular issue and the issue seemed relevant to the discussion.
Jonathan
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Patrick H. Lauke
Sent: Thursday, January 4, 2018 6:18 PM
To: = EMAIL ADDRESS REMOVED =
Subject: Re: [WebAIM] Making mobile view available to all as way of constraining a11y testing costs
On 04/01/2018 23:05, Jonathan Avila wrote:
>> 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?
>
> Because I use low resolution on desktop or some browser zoom I find myself almost always entering mobile breakpoints on my desktop . In my experience page zoom not only changes the viewport with but also the scale factor. So the text size of sites is different at a width of 533 then it would be by zooming to say 150% that gets me to 533 (number made up) but also has a scale factor of 1.5.
I'm sure we've had this conversation many times before, but: using page zoom effectively changes how many physical/screen pixels make up a CSS pixel. So yes, full-page zoom will result in everything being bigger by that factor, and the reported viewport width being smaller by that same factor.
> Thus there is a larger opportunity for non-fluid responsive sites to have issues such as text that is cutoff or overflows over other text or text over a different background without sufficient contrast.
Do you have actual examples where this happens? Because it's not really a given that responsive sites would cause more or less cutoffs/overflowing, since every measure (be it a measure set in pixels, or ems, or whatever) is scaled exactly the same way.
> A truly fluid site would not have these issues but in my experience most sites really aren't truly fluid but instead are a series of breakpoints.
Do you have actual examples of a "truly fluid" site versus a "non-fluid responsive" site?
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
From: Patrick H. Lauke
Date: Fri, Jan 05 2018 6:26PM
Subject: Re: Making mobile view available to all as way of constraining a11y testing costs
← Previous message | Next message →
On 05/01/2018 23:37, Jonathan Avila wrote:
>> [Patrick wrote] Do you have actual examples where this happens?
>
> This Hampton Inn site is not responsive but provides an example of when you zoom in and scrollbars appear text is pushed off to the right. When you scroll over to read the text the white text in the banner links can't be read because it no longer appears on a blue background but on a white background. In this case the container is a fixed width. I haven't diagnosed specifically what is happening but I'd imagine that this could happen to a responsive site that was not truly fluid. A responsive site can simply be a set of breakpoints on fixed width elements.
>
> http://hamptoninn3.hilton.com/
Good lord, I'm glad to say I've not come across such a borked layout in
a while. Digging into it, the site's layout relies on a series of
absolutely positioned a floated (but not cleared) elements, which have
been carefully crafted to give the appearance of a cohesive layout. But
yes, once you zoom to the point where scrollbars appear, the content
that is causing the scrollbars (as it's wider than the browser window)
is not causing the body to also increase in width (as it's either
absolutely positioned or floated, thus taken out of the regular set of
elements that give containers their width). And as the elements that
have the background colour are set to 100% width of the body, they
simply stop.
So good point, there are still ways (when layouts are built in such a
broken way) where zooming (including full-page zooming) can cause
problems (even though all the measurements themselves scaled at the same
pace / by the same factor, the elements that did have the background
were locked to only be as wide as the body, which in the absence of an
explicit width being set, and in the absence of elements that directly
contribute to its width, will only be as wide as the window/viewport).
And yes, if media query breakpoints are then simply used to switch
between one of these broken layouts to another one, then any in-between
viewport sizes / zoom factors have the potential of being broken. I'd
argue that's not "real" responsive web design (as the idea is that the
site/layout responds to the width of the viewport and adapts its content
to it, not just for a particular set of breakpoints but for - within
reason - any viewport size), but that risks going down the "no true
scotsman" route.
Incidentally, a site doesn't even need to be fully fluid to not break
this way. It just needs to avoid building brittle/broken layouts that
rely on absolute positioned elements, floated elements, and regular
elements that then visually (but not really, since the other elements
are not contributing to the width) act as containers. For instance, the
main http://www.hiltonworldwide.com/ site is not responsive, and not
fluid, but at least when you zoom and scroll, nothing breaks.
> I haven't reviewed the site for accessibility -- but just happened to see this particular issue and the issue seemed relevant to the discussion.
Excellent example / cautionary tale (though perhaps not directly about
RWD per se, but more about "even full-page zoom does not guarantee
things don't break"). Cheers.
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
From: Mallory
Date: Wed, Jan 10 2018 2:17AM
Subject: Re: Making mobile view available to all as way of constraining a11y testing costs
← Previous message | Next message →
>Do you have actual examples where this happens? Because it's not really
a given that responsive sites would cause more or less
cutoffs/overflowing, since every measure (be it a measure set in pixels,
or ems, or whatever) is scaled exactly the same way.
So Twitter goes responsive (text in menus turn into icons, the left-side thingie goes away) but if I want to log out, I need to zoom waaaaaay the hell out because they forgot that sticky headers with dropdown menus are poop. If my screen was as large as those Silicon-valley designers it probably would still fit but I'm on a Lenovo stinkpad, like 12" or something.
They check widths in their responsiveness but I guess they forgot about heights.
cheers,
Mallory
On Fri, Jan 5, 2018, at 12:18 AM, Patrick H. Lauke wrote:
> On 04/01/2018 23:05, Jonathan Avila wrote:
> >> 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?
> >
> > Because I use low resolution on desktop or some browser zoom I find myself almost always entering mobile breakpoints on my desktop . In my experience page zoom not only changes the viewport with but also the scale factor. So the text size of sites is different at a width of 533 then it would be by zooming to say 150% that gets me to 533 (number made up) but also has a scale factor of 1.5.
>
> I'm sure we've had this conversation many times before, but: using page
> zoom effectively changes how many physical/screen pixels make up a CSS
> pixel. So yes, full-page zoom will result in everything being bigger by
> that factor, and the reported viewport width being smaller by that same
> factor.
>
> > Thus there is a larger opportunity for non-fluid responsive sites to have issues such as text that is cutoff or overflows over other text or text over a different background without sufficient contrast.
>
> Do you have actual examples where this happens? Because it's not really
> a given that responsive sites would cause more or less
> cutoffs/overflowing, since every measure (be it a measure set in pixels,
> or ems, or whatever) is scaled exactly the same way.
>
> > A truly fluid site would not have these issues but in my experience most sites really aren't truly fluid but instead are a series of breakpoints.
>
> Do you have actual examples of a "truly fluid" site versus a "non-fluid
> responsive" site?
>
> 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
> > > >
From: Patrick H. Lauke
Date: Wed, Jan 10 2018 3:05AM
Subject: Re: Making mobile view available to all as way of constraining a11y testing costs
← Previous message | Next message →
On 10/01/2018 09:17, Mallory wrote:
>> Do you have actual examples where this happens? Because it's not really
> a given that responsive sites would cause more or less
> cutoffs/overflowing, since every measure (be it a measure set in pixels,
> or ems, or whatever) is scaled exactly the same way.
>
> So Twitter goes responsive (text in menus turn into icons, the left-side thingie goes away) but if I want to log out, I need to zoom waaaaaay the hell out because they forgot that sticky headers with dropdown menus are poop. If my screen was as large as those Silicon-valley designers it probably would still fit but I'm on a Lenovo stinkpad, like 12" or something.
>
> They check widths in their responsiveness but I guess they forgot about heights.
That would also happen if they weren't using responsive web design. It's
just bad design, period.
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
From: Patrick H. Lauke
Date: Wed, Jan 10 2018 3:13AM
Subject: Re: Making mobile view available to all as way of constraining a11y testing costs
← Previous message | Next message →
On 10/01/2018 10:05, Patrick H. Lauke wrote:
> On 10/01/2018 09:17, Mallory wrote:
>>> Do you have actual examples where this happens? Because it's not really
>> a given that responsive sites would cause more or less
>> cutoffs/overflowing, since every measure (be it a measure set in pixels,
>> or ems, or whatever) is scaled exactly the same way.
>>
>> So Twitter goes responsive (text in menus turn into icons, the
>> left-side thingie goes away) but if I want to log out, I need to zoom
>> waaaaaay the hell out because they forgot that sticky headers with
>> dropdown menus are poop. If my screen was as large as those
>> Silicon-valley designers it probably would still fit but I'm on a
>> Lenovo stinkpad, like 12" or something.
>>
>> They check widths in their responsiveness but I guess they forgot
>> about heights.
>
> That would also happen if they weren't using responsive web design. It's
> just bad design, period.
In fact, beyond a few tiny changes (the most visible one being that
dropping of text from the menu at <800px), www.twitter.com isn't really
a responsive site. The issue with the cut-off dropdown happens at all
sizes when the height of the browser window is less than the dropdown
length. Would also happen exactly the same way if you forced just
text-only resizing or similar. It's not intrinsically a "responsive web
/ full-page zoom" type problem, but yes a "just badly designed in
general" one.
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
From: Mallory
Date: Wed, Jan 10 2018 5:02AM
Subject: Re: Making mobile view available to all as way of constraining a11y testing costs
← Previous message | Next message →
I can go with that :P
On Wed, Jan 10, 2018, at 11:13 AM, Patrick H. Lauke wrote:
> On 10/01/2018 10:05, Patrick H. Lauke wrote:
> > On 10/01/2018 09:17, Mallory wrote:
> >>> Do you have actual examples where this happens? Because it's not really
> >> a given that responsive sites would cause more or less
> >> cutoffs/overflowing, since every measure (be it a measure set in pixels,
> >> or ems, or whatever) is scaled exactly the same way.
> >>
> >> So Twitter goes responsive (text in menus turn into icons, the
> >> left-side thingie goes away) but if I want to log out, I need to zoom
> >> waaaaaay the hell out because they forgot that sticky headers with
> >> dropdown menus are poop. If my screen was as large as those
> >> Silicon-valley designers it probably would still fit but I'm on a
> >> Lenovo stinkpad, like 12" or something.
> >>
> >> They check widths in their responsiveness but I guess they forgot
> >> about heights.
> >
> > That would also happen if they weren't using responsive web design. It's
> > just bad design, period.
>
> In fact, beyond a few tiny changes (the most visible one being that
> dropping of text from the menu at <800px), www.twitter.com isn't really
> a responsive site. The issue with the cut-off dropdown happens at all
> sizes when the height of the browser window is less than the dropdown
> length. Would also happen exactly the same way if you forced just
> text-only resizing or similar. It's not intrinsically a "responsive web
> / full-page zoom" type problem, but yes a "just badly designed in
> general" one.
>
> 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
> > > >
From: Tim Harshbarger
Date: Thu, Jan 11 2018 6:47AM
Subject: Re: Making mobile view available to all as way of constraining a11y testing costs
← Previous message | Next message →
I want to revisit an earlier part of the discussion.
If you do decide to test only one view of the site to limit testing costs, you should also clearly state to your users which view is the accessible one. Users should not have to switch back and forth between views of your site to figure out which one is accessible.
If you do decide to test multiple break points or view of the content, you should be able to keep the costs down by doing a few things and developing some experience with the process.
My suggestion would be to decide that one view or break point is going to be the version of the content you will test all the way through. Then you only test the significant differences in the other views.
In order to do this, you are going to need to walk-through the designs for the site or the site itself--or rely on someone who knows it well. Also, over time you will get a better idea of what differences are significant enough to test and which ones don't need to be tested.
Honestly, no one should be surprised that accessibility testing for a responsive site costs more. It costs more to test responsive sites in general. I think you could say that deciding to perform accessibility testing on only one view of the content would be like only performing testing with a desktop browser for a responsive site.
However, I am sure we all recognize that we don't always get the resources we want for accessibility testing so we have to do the best with what we are given. Robert is definitely doing his best to try to figure out how to conduct accessibility testing within the boundaries he is given--which really isn't any different from anything else having to do with software engineering.
I dislike the limitations we find ourselves dealing with, but I do admire how creative our community can be in trying to figure out how to get things done within those limitations.
From: Patrick H. Lauke
Date: Thu, Jan 11 2018 7:03AM
Subject: Re: Making mobile view available to all as way of constraining a11y testing costs
← Previous message | Next message →
On 11/01/2018 13:47, Tim Harshbarger wrote:
> I want to revisit an earlier part of the discussion.
>
> If you do decide to test only one view of the site to limit testing costs, you should also clearly state to your users which view is the accessible one. Users should not have to switch back and forth between views of your site to figure out which one is accessible.
Noting that if the switching happens based on things like viewport size
outside the user's control, then that won't fly. But yes, if there's an
actual link/button/setting that lets users switch, agree that it should
be made clear which one is and which one isn't "accessible" (or at least
has been tested as being accessible).
[...]
> However, I am sure we all recognize that we don't always get the resources we want for accessibility testing so we have to do the best with what we are given. Robert is definitely doing his best to try to figure out how to conduct accessibility testing within the boundaries he is given--which really isn't any different from anything else having to do with software engineering.
> I dislike the limitations we find ourselves dealing with, but I do admire how creative our community can be in trying to figure out how to get things done within those limitations.
Oh absolutely, apologies if my remarks in this thread came across as a
slight against Robert. I saw for the pragmatic proposal it was, just
pointing out that it's not ideal and why.
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
From: Robert Fentress
Date: Thu, Jan 11 2018 11:42AM
Subject: Re: Making mobile view available to all as way of constraining a11y testing costs
← Previous message | No next message
Thanks, again, for the feedback. Perhaps I am just straining at gnats, as
is my wont. It may suffice to use common sense in identifying what
specific content needs to be checked at the different breakpoints, and I
shouldn't worry too much that I may be missing something. Still, I like
the idea of providing a visible option for users to switch to a
presentation that would ordinarily only be available at the smaller
viewport. Often, it is simpler and less cluttered.
On Thu, Jan 11, 2018 at 9:03 AM, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = >
wrote:
> On 11/01/2018 13:47, Tim Harshbarger wrote:
>
>> I want to revisit an earlier part of the discussion.
>>
>> If you do decide to test only one view of the site to limit testing
>> costs, you should also clearly state to your users which view is the
>> accessible one. Users should not have to switch back and forth between
>> views of your site to figure out which one is accessible.
>>
>
> Noting that if the switching happens based on things like viewport size
> outside the user's control, then that won't fly. But yes, if there's an
> actual link/button/setting that lets users switch, agree that it should be
> made clear which one is and which one isn't "accessible" (or at least has
> been tested as being accessible).
>
> [...]
>
>> However, I am sure we all recognize that we don't always get the
>> resources we want for accessibility testing so we have to do the best with
>> what we are given. Robert is definitely doing his best to try to figure out
>> how to conduct accessibility testing within the boundaries he is
>> given--which really isn't any different from anything else having to do
>> with software engineering.
>> I dislike the limitations we find ourselves dealing with, but I do admire
>> how creative our community can be in trying to figure out how to get things
>> done within those limitations.
>>
>
> Oh absolutely, apologies if my remarks in this thread came across as a
> slight against Robert. I saw for the pragmatic proposal it was, just
> pointing out that it's not ideal and why.
>
> 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>