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<mailto:jon.avila@ssbbartgroup.com>
703.637.8957 (Office)

Visit us online: Website<http://www.ssbbartgroup.com/> | Twitter<https://twitter.com/SSBBARTGroup> | Facebook<https://www.facebook.com/ssbbartgroup> | Linkedin<https://www.linkedin.com/company/355266?trk=tyah> | Blog<http://www.ssbbartgroup.com/blog/>
Join SSB at Accessing Higher Ground This Month!<http://www.ssbbartgroup.com/blog/join-ssb-accessing-higher-ground-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.4<http://www.w3.org/TR/2008/REC-WCAG20-20081211/#visual-audio-contrast-scale>Resize text: Except for captions<https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-scale.html#captionsdef>and images of text<https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-scale.html#images-of-textdef>, text<https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-scale.html#textdef>can be resized without assistive technology<https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-scale.html#atdef> 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<https://www.w3.org/blog/2016/10/wcag-2-1-under-exploration/> 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<mailto:pjenkins@us.ibm.com>





From:        "Patrick H. Lauke" <redux@splintered.co.uk<mailto:redux@splintered.co.uk>>
To:        w3c-wai-ig@w3.org<mailto: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<http://redux.deviantart.com/>
twitter: @patrick_h_lauke | skype: patrick_h_lauke