RE: Agenda for AGWG Call, Tuesday May 1, 2018

Ø  So I think most people would agree that we should test across sizes & breakpoints [1] in responsive design, BUT, is anyone arguing for a multiplier effect? E.g. testing every SC when text-spacing is on?

It looks like we are set to keep testing of different sizes and breakpoints as that is covered by the conformance note.  The question is then around other areas.  I am pretty certain that changes to text spacing will also break contrast in a lot of places and may also cause overlapping text.  I also understand the multiplier of possibilities.

It seems like contrast 1.4.3 and possibly 1.4.11 non-text contrast of UI elements can be broken unintentionally by SC 1.4.4 resize and SC 1.4.12 text spacing and not be caught by the testing of different breakpoints.  Some of these might also fail SC 1.4.10 reflow and it would be caught there.  So we might want to create a matrix to uncover the possible interaction points.

We also need to work out how to interpret Orientation.

Jonathan

From: Alastair Campbell [mailto:acampbell@nomensa.com]
Sent: Wednesday, May 02, 2018 4:05 AM
To: Jonathan Avila; Katie Haritos-Shea
Cc: WCAG
Subject: Re: Agenda for AGWG Call, Tuesday May 1, 2018

Hi Jonathan,

I’m agreeing with your point in general, but I’d tease out two types of issue which impact testing:


  1.  Deliberate changes at different breakpoints. For example:
Changing a widget type at smaller sizes (1.3.1)
Removing text next to an icon at smaller sizes, bringing the icon into non-text contrast scope (1.4.11)
  2.  Un-intentional layout/text flow issues such as your example. (Which is a unit-mismatch issue with text inside an container sized to the window.)

I agree that if a widget at smaller sizes doesn’t meet 1.3.1 / 4.1.2 that is an issue as it affects anyone using a phone screenreader.

For things which are deliberate it is easier to talk to the developers and/or notice the change, and focus on that in testing. For un-inentional things we can have the multiplier effect in testing.

So I think most people would agree that we should test across sizes & breakpoints [1] in responsive design, BUT, is anyone arguing for a multiplier effect? E.g. testing every SC when text-spacing is on?

Cheers,

-Alastair

1] Note that layout & text-flow changes between breakpoints as well as across them if the site uses a percentage, responsive layout.
Responsive layout = flexible + breakpoints.
Adaptive layout = fixed + breakpoints


From: Jonathan Avila <jon.avila@levelaccess.com>
Date: Wednesday, 2 May 2018 at 01:05
To: Katie Haritos-Shea <ryladog@gmail.com>, Alastair Campbell <acampbell@nomensa.com>
Cc: WCAG List <w3c-wai-gl@w3.org>
Subject: RE: Agenda for AGWG Call, Tuesday May 1, 2018

A simple example like the following puts white text over a white background when you zoom in.   The content is still there – the contrast is just 0.
http://mraccess77.github.io/reflow.html


Zooming may or may not trigger responsive breakpoints.  Breakpoints, fluid sites, or other methods will be needed for SC 1.4.10.  If we don’t need to test other SCs for different breakpoints and the zoom user is forced into the breakpoint then there can be issues that the low vision user is forced into but prevent him/her from using the page.  For example, I’ve seen keyboard accessible pages that when flipped into a responsive view have keyboard focus issues because suddenly something that was displayed in one view is layered behind content in a responsive view but not taken out of the focus order.  I’ve also seen radio buttons that morph into combo boxes in different responsive views.   The roles of these items don’t reflect the new visual meaning failing SC 1.3.1 and breaking keyboard patterns.  So at the very least we have to test each breakpoint that the zoom user will be thrown into NOT by our choice.  We can’t say ok—you can zoom in but the site doesn’t actually have to have sufficient contrast anymore.  Or you can zoom in but now there is no indication of keyboard focus.  What’s the point of zooming in if the site then fails the other requirements of WCAG?  The content and functionality may be there but users can’t actually use it.  That seems to go against the intent of the having the functionality and content be available.

Jonathan


From: Katie Haritos-Shea <ryladog@gmail.com>
Sent: Tuesday, May 1, 2018 7:48 PM
To: Alastair Campbell <acampbell@nomensa.com>
Cc: WCAG <w3c-wai-gl@w3.org>
Subject: Re: Agenda for AGWG Call, Tuesday May 1, 2018

Thank you Alastair, I had just never thought about where a page reflows and would shift the text around over a background before - other than for text in SPAs - where we always suggest having a border or blur around text to accommodate any change to the background behind the text for 1.4.3. I don't think I have ever seen an example like the Hilton site before.

I want to weigh in on the combining SC issue - I am not for it. It adds too many layers of complexity. Each requirement needs to be testable independently IMO. If one wants that, one needs a SC that combines such things, as in the 1.4.12 that combines line height, letter spacing, paragraph spacing and word spacing wrapped into one SC.


* katie *

Katie Haritos-Shea
Principal ICT Accessibility Architect

WCAG/Section 508/ADA/AODA/QA/FinServ/FinTech/Privacy, IAAP CPACC+WAS = CPWA<http://www.accessibilityassociation.org/cpwacertificants>

Cell: 703-371-5545<tel:703-371-5545> | ryladog@gmail.com<mailto:ryladog@gmail.com> | Oakton, VA | LinkedIn Profile<http://www.linkedin.com/in/katieharitosshea/>

People may forget exactly what it was that you said or did,
but people will never forget how you made them feel.......

Our scars remind us of where we have been........they do not have to dictate where we are going.

On Tue, May 1, 2018 at 7:00 PM, Alastair Campbell <acampbell@nomensa.com<mailto:acampbell@nomensa.com>> wrote:
Katie wrote:
> The contrast change that Jon demonstrated (thanks that this was in the minutes) Hilton site is something I was entirely unaware of. Thanks for bring it to our attention, apparently again.....:-)

Just to note, that’s a non-responsive site that has somehow managed to find a way to not expand a background whilst everything else expands. Some absolute positioning and z-index stuff going on there.

You can see the logo in the top right stay fixed to the viewport, whilst the rest of the layout expands underneath.

If something fails 1.4.10 like this, I don’t think you can fail it on contrast on top of that? It isn’t providing other views (in the way the new note describes), so simply fails on 1.4.10

There are examples where a page reflows and text shifts around over a background though, which is where the question came from.

Cheers,

-Alastair