Re: How 1.4.4 Resize text applies when mobile templates kick in

I think your point: 
"don't completely omit content/functionality at different breakpoints as 
it will affect all users and particularly LV users with zoom"

a. is not well understood by designers.
b. is harder to do than we accessibility SME's think, otherwise if it was 
easy then designers would be doing it.
c. many actually think less is better, especially for simplicity and ease 
of use, less cognitive load on the user, etc. 
in other words, that reducing the screen size and thereby reducing the 
content & functionality is actually the goal for some designers. 
Have you noticed how much vertical scrolling that goes on these days in 
newly designed sites? 

I also think this is another example of where there are some conflicting 
and missunderstood requirements, hence one possible reasons this is level 
AA and the need to balance the role of the assistive technology.  Maybe 
that's why the working group "capped" it at 2x for browser?  that's what I 
remember anyway.

1.4.4 Resize text: Except for captions and images of text, text can be 
resized without assistive technology up to 200 percent without loss of 
content or functionality. (Level AA)  

As suggested by others, we need some more specifications and rules on 
passing and failures with screen resolutions and browser widths (e.g. 
breakpoints) since those didn't exist back in the day when WCAG 2.0 was 
sent to candidate recommendation. For example, when the browser width is 
reduced to a breakpoint, and the design changes, should the 2X zoom then 
be applied before or after and test for loss of functionality?  Seems that 
some are incorrectly suggesting that the "responsive design" should not 
loose content or functionality.  I don't recall us ever demanding that 
mobile web sites (m dot's) have the same content and functionality as 
desktop web sites, not as an accessibility requirement.  Why now?  I'm 
suggesting that the cause or trigger that is causing the responsive design 
to be rendered be done first, then zoom that 2X, and then check if there 
is loss of content or functionality.  In otherwords, responsive change 
should not be be considered when evaluating if loss of content or 
functionality occured - was there loss because of zoom or because of 
narrower width?  I think the definition of "loss of content or 
functionality" needs a glossary entry (not one in 2.0 currently) and some 
enhanced explanations and additional up-to-date examples with responsive 
design and breakpoints in the Understanding doc.  The examples in 
Understanding WCAG 2.0 today only address 3 old (older than a decade) 
examples:
1. All the information on the page is still displayed. 
2. Selecting different settings changes the layout of the page to use the 
best design for that scale. 
3. All the content scales uniformly, and the user agent provides scroll 
bars, if necessary. 
See 
https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-scale.html#visual-audio-contrast-scale-examples-head


How is this being addressed in WCAG 2.1?  it is on the list to be 
considered, correct?

WCAG 2.1 under exploration  The Web Content Accessibility Guidelines 
Working Group announces a plan to develop WCAG 2.1, which builds on but 
does not supersede WCAG 2.0. We request feedback as early as possible, and 
by 1 November 2016. (2016-10-12)
___________
Regards,
Phill Jenkins
pjenkins@us.ibm.com





From:   "Patrick H. Lauke" <redux@splintered.co.uk>
To:     w3c-wai-ig@w3.org
Date:   11/07/2016 02:30 PM
Subject:        Re: How 1.4.4 Resize text applies when mobile templates 
kick in



On 07/11/2016 18:39, Phill Jenkins wrote:
> I also think this is an example of a potential issue where when the
> feature is "built in" to the browser for everyone,  everyone may not use
> it in the same way.  The web site designer is thinking that the better
> experience is for the end user to see the site be more responsive and
> render the narrow phone breakpoint view, while the low vision user is
> just trying to zoom in to see the site better.

But if the site doesn't reflow responsively - as in the case of old 
non-responsive fixed-width sites - all you'd get is horizontal 
scrolling. So I think designers are doing the right thing / browsers are 
doing the right thing...when the user zooms, the *effective* pixel width 
is reduced (zooming in simply scales up each pixel measure), and with 
responsive design authors can define how to best make use of that 
particular width/size of viewport.

What's really at issue is that authors should not completely omit 
content/functionality just because a viewport is smaller. It's a 
usability problem for all users, but disproportionately affects low 
vision users who may be using zoom functionality, so it's an 
accessibility issue?

>  Isn't this really a
> requirement for the user agent (browser) to handle (not the web
> designer) because each user is different and may want a different
> reaction to the zooming?  As we say, one size does not fit all.  In
> other words, some users will want the zooming to NOT trigger the
> responsive design to kick-in, other users WILL want it to respond at the
> same zoom and width.  Users may want the experience on some site and not
> on others BECAUSE it may depend on that site's particular design vs
> always having the zoom feature trigger it.

So that would require all UAs to implement a different new zoom 
mechanism. In the meantime, authors would need to build some form of 
"zoom, but not responsively" mechanism into their sites? Not quite sure 
that'd be the best way forward, compared to a fairly straightforward 
"don't completely omit content/functionality at different breakpoints as 
it will affect all users and particularly LV users with zoom"

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