W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > January to March 2016

RE: Allowing font size changes

From: Jonathan Avila <jon.avila@ssbbartgroup.com>
Date: Tue, 19 Jan 2016 15:17:48 +0000
To: Phill Jenkins <pjenkins@us.ibm.com>, "w3c-wai-ig@w3.org" <w3c-wai-ig@w3.org>
Message-ID: <BY2PR03MB2723AC63278784E41C540DA9BC10@BY2PR03MB272.namprd03.prod.outlook.com>
[Phil wrote] I agree it is a user agent responsibility *and* an end user responsibility to
know how to set the setting or have an assistant set it for them.  It is a lot
easier and more efficient to set it once per browser and/or per OS platform
that to try to find the yet another unique way an individual website / developer did it.
Using the excuse that some browser or platforms are hard to set & use does not justify
leaving it up to millions of web developers to try to figure it out.

We seem to agree on the following:

  Pinch zoom and text resize without horizontal scroll are different

  Pinch zoom meets current WCAG conformance requirements if text resizes up to 200% without loss of functionality

  WCAG conformance can be met by providing text resize controls that enlarge all text up to 200% without loss of functionality (not generally recommend approach but sufficient)

  Text resize may be preferable for many users

  User agents and platforms should provide a method to enlarge text content

The challenge is that it may be difficult for authors to respond to a wide range of text size changes without creating horizontal scrolling.  Yes, responsive sites can be used but these may be based on breakpoints that may not exist smaller than the width of a mobile device.  If the user wants to resize text on a mobile device the author would need to plan for that even if the site is responsive.  What many sites do is keep the UI static but allow for text resize of the main content area - yes, this is similar to the "reader" mode some user agents and platforms offer.  My point though is that responding to larger text settings in the OS does require work by the author just as adding controls to resize text requires work by the author.  Simply offering the settings in the user agent and exposing them to the page does not guarantee they will automagically make the page content work correctly.

In addition, pinch zoom on a mobile device can be broken surprisingly easily.   For example, by use a floating fixed position bar at the top of the page.  When the page is zoomed the bar takes up most of the display leaving no room to view the page contents.   So authors need some flexibility in how they meet the SC.

Jonathan

Jonathan Avila
Chief Accessibility Officer
SSB BART Group
jon.avila@ssbbartgroup.com
703.637.8957 (o)
Follow us: Facebook<http://www.facebook.com/#!/ssbbartgroup> | Twitter<http://twitter.com/#!/SSBBARTGroup> | LinkedIn<http://www.linkedin.com/company/355266?trk=tyah> | Blog<http://www.ssbbartgroup.com/blog> | Newsletter<http://eepurl.com/O5DP>

From: Phill Jenkins [mailto:pjenkins@us.ibm.com]
Sent: Monday, January 18, 2016 5:35 PM
To: w3c-wai-ig@w3.org
Subject: Re: Allowing font size changes

> The OS and browser are each broken if they don't provide a way to increase
> font size, and zoom - yes they are different. And both have important uses.

I agree it is a user agent responsibility *and* an end user responsibility to
know how to set the setting or have an assistant set it for them.  It is a lot
easier and more efficient to set it once per browser and/or per OS platform
that to try to find the yet another unique way an individual website / developer did it.
Using the excuse that some browser or platforms are hard to set & use does not justify
leaving it up to millions of web developers to try to figure it out.

> I'm not sure there is any absolute requirement that authors add a
> redundant shortcut to do the same,

I agree, only to make sure their app doesn't break when zooming at 2X
see WCAG 1.4.4 Resize Text http://www.w3.org/TR/WCAG20/#visual-audio-contrast-scale

> but in practice it can be a useful thing for many users, especially given that
> in practice many OS and browser solutions are hard to find or use.

I believe it is more useful and less confusing when the audience of the web app is known or controlled
and has had some training or orientation, such as employees of a company with a particular app,
or when the app is being designed specifically for a group of users who have the same or know disability, such as
a rehabilitation app.

The advocacy effort here needs to be directed at OS platform and browser developers and AT developers, not web developers.
We are starting to get good traction with the iOS and Andorid app developers not that so many accessibility features
are now included in the platform.

Why can't we (meaning the web accessibility community) focus on the handful of platform and browser developers
and stop wasting our time and the millions of web developers time on this topic?
____________________________________________
Regards,
Phill Jenkins,




From:        "Chaals McCathie Nevile" <chaals@yandex-team.ru<mailto:chaals@yandex-team.ru>>
To:        w3c-wai-ig@w3.org<mailto:w3c-wai-ig@w3.org>
Date:        01/18/2016 02:00 PM
Subject:        Re: Allowing font size changes
________________________________



On Fri, 15 Jan 2016 15:46:19 +0100, Patrick H. Lauke
<redux@splintered.co.uk<mailto:redux@splintered.co.uk>> wrote:

> But as ever, it comes down to whose responsibility it is? Should it be
> the content authors, or the device/OS/browser manufacturers?

The OS and browser are each broken if they don't provide a way to increase
font size, and zoom - yes they are different. And both have important uses.

I'm not sure there is any absolute requirement that authors add a
redundant shortcut to do the same, but in practice it can be a useful
thing for many users, especially given that in practice many OS and
browser soutions are hard to find or use.

IMHO.

chaals

> P
>
> On 15/01/2016 14:40, ALAN SMITH wrote:
>> Heather,
>>
>> I agree.
>>
>> Imaging having to set the volume on our devices in a settings somewhere
>> and constantly return to that setting after we find out it is not enough
>> or too much and not having the immediate feedback afforded by volume
>> buttons or onscreen controls.
>>
>> Same should be provided for fonts.
>>
>> After all, the text on the web page or app is the main mode of
>> communication or human computer interaction.
>>
>> It is why we use these devices anyway: to be able to read the text being
>> used.
>>
>> The world population that needs this is so big.
>>
>> Regards,
>>
>> Alan
>>
>> Sent from Mail <http://go.microsoft.com/fwlink/?LinkId=550986> for
>> Windows 10
>>
>>
>> *From: *Durham, Heather <mailto:heather.durham@pearson.com>
>> *Sent: *Friday, January 15, 2016 9:25 AM
>> *To: *howard_leicester@btconnect.com<mailto:*howard_leicester@btconnect.com>
>> <mailto:howard_leicester@btconnect.com>
>> *Cc: *Patrick H. Lauke <mailto:redux@splintered.co.uk>;
>> w3c-wai-ig@w3.org<mailto:w3c-wai-ig@w3.org> <mailto:w3c-wai-ig@w3.org>
>> *Subject: *Re: Allowing font size changes
>>
>> What will be the plan for the app? Will it be widely used on mobile
>> devices? In mobile devices you can increase the font size, but it's not
>> as convenient as in a web page. On mobile devices you need to go to the
>> settings app and you can't see how the font size looks live as you
>> adjust it. For people who have difficulty navigating, it could be a real
>> convenience to tap a button to increase the font size right there in the
>> app their using.
>>
>> This could also be a nice feature for other uses, such as those with
>> autism. I attended an autism conference in the summer and this was
>> something that was widely discussed. The convenience of reducing the
>> number of steps to accomplish something.
>>
>> Thanks,
>>
>> Heather
>>
>> On Thu, Jan 14, 2016 at 3:22 PM, Howard Leicester
>> <howard_leicester@btconnect.com <mailto:howard_leicester@btconnect.com>>
>> wrote:
>>
>>     Hi P et al,
>>
>>     Do things really have to be so detailed and difficult?
>>
>>     May be there's some more fundamentally wrong in our approach?
>>
>>     No criticism, just a view!
>>
>>     VV best,
>>     Howard (Leicester, UK).
>>
>>
>>
>>     -----Original Message-----
>>     From: Patrick H. Lauke [mailto:redux@splintered.co.uk
>>     <mailto:redux@splintered.co.uk>]
>>     Sent: 14 January 2016 01:23
>>     To: w3c-wai-ig@w3.org<mailto:w3c-wai-ig@w3.org> <mailto:w3c-wai-ig@w3.org>
>>     Subject: Re: Allowing font size changes
>>
>>     On 14/01/2016 00:52, Oscar Cao wrote:
>>     > I want to get what everyone's views are on the importance of
>> having
>>     > custom font size buttons for a website. You know those 3 icon
>> buttons:
>>     > smaller, medium, and larger.
>>
>>     Very low from my point of view. It's functionality built into the
>>     browser already, so provided a site's CSS is made correctly, these
>>     in-page controls would be redundant.
>>
>>     There is an argument that users simply don't know that they can
>> resize
>>     text/content using the browser controls - but this is more of a user
>>     education issue that should not have to be the responsibility of
>> content
>>     authors. (same for in-page/custom controls to switch to high
>> contrast
>>     mode or similar)
>>
>>     P
>>     --
>>     Patrick H. Lauke
>>
>>     www.splintered.co.uk <http://www.splintered.co.uk<http://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
>>
>>
>>
>>
>> --
>>
>> Heather Durham
>>
>> Accessibility SQA, HEd
>>
>> Pearson North America
>>
>> 2154 East Commons Ave.
>>
>> Suite 4000
>>
>> Centennial, CO
>>
>> 80122
>>
>> USA
>>
>> *Pearson *
>>
>> Always Learning
>> Learn more at www.pearson.com <http://www.pearson.com/>
>>
>
>


--
Charles McCathie Nevile - web standards - CTO Office, Yandex
 chaals@yandex-team.ru<mailto:chaals@yandex-team.ru> - - - Find more at http://yandex.com<http://yandex.com/>
Received on Tuesday, 19 January 2016 15:18:24 UTC

This archive was generated by hypermail 2.3.1 : Friday, 29 January 2016 16:39:04 UTC