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

> Neither of those options are acceptable
I agree we have an issue if we only consider the built-in zoom in today's 
current browsers.  So the user either needs to add on AT, that the web 
site design and/or browser don't know about, or we need to get browsers to 
give us the option. I need to re-check how Safari on iOS works when zoomed 
for example.  And we need to inform web designers of the issues until the 
browser manufactures make improvements and resolution testing guidelines 
are better established. 

Again in my opinion it falls into the one-size-fits-all everything free in 
the browser thinking that got us here in the first place.  Accessibility 
is still journey.
___________
Regards,
Phill Jenkins
pjenkins@us.ibm.com





From:   Jonathan Avila <jon.avila@ssbbartgroup.com>
To:     "w3c-wai-ig@w3.org" <w3c-wai-ig@w3.org>
Date:   11/08/2016 01:10 PM
Subject:        RE: How 1.4.4 Resize text applies when mobile templates 
kick in



Ø   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 would then ask how I am supposed to access content without using a 
screen resolution I can?t use?  If I use 800x600 or 1024x768 and content 
is not displayed at those resolutions that I need and there is no link to 
access it would am I supposed to do?  I only have two options ? zoom out 
to make the content smaller thus trigger a desktop breakpoint or set my 
resolution higher to trigger a desktop breakpoint.  Neither of those 
options are acceptable.
 
I would also say that when we talk about responsive sites we aren?t 
talking about mobile ? we are just talking about responsive sites.  Mobile 
devices just happen to be one situation where responsive breakpoints are 
triggered but they certainly aren?t the only.
 
Jonathan
 
Jonathan Avila
Chief Accessibility Officer
SSB BART Group 
jon.avila@ssbbartgroup.com
703.637.8957 (Office)
 
Visit us online: Website | Twitter | Facebook | Linkedin | Blog
Join SSB at Accessing Higher Ground This Month!
 
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.
 
From: Phill Jenkins [mailto:pjenkins@us.ibm.com] 
Sent: Monday, November 07, 2016 7:41 PM
To: public-comments-wcag20@w3.org
Cc: w3c-wai-ig@w3.org
Subject: 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.4Resize text: Except for captionsand images of text, textcan 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