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

Re: Allowing font size changes

From: Phill Jenkins <pjenkins@us.ibm.com>
Date: Mon, 18 Jan 2016 20:03:25 -0600
To: WAI Interest Group <w3c-wai-ig@w3.org>
Message-ID: <OFB0529BF1.0FE51A09-ON86257F3F.00073505-86257F3F.000B4D53@us.ibm.com>
Hi Wayne,
good  discussion, and I agree with the direction. 

I agree Authors own the structure, but re-designing a web site for 
Responsive smart phone browsers is not trivial and is taking many 
companies many months (years?) and hundreds of developers to do it.  IBM 
Mobile First even advocates and provides tooling for responsive design. 
But again it is not trivial and has taken years to get to this point. 
I would like to see the authoring tool vendors, toolkit developers, and 
browser to assess the effort to support the extension to large screens 
with very large fonts first before or while we start advocating any 
specific techniques.  I am always cautious when I expect authors to 
preform very specialized work that previously was Assistive Technology 
product design work - because authors often have no idea what they are 
looking at or what is needed and we end up with all kinds of crazy 
solutions.  It would only be trivial to extend those techniques IF 
authoring tools, widget toolkits, automated testing tools and browser 
supported them.  For example, Responsive design is only happening BECAUSE 
authors have smartphone browsers, and now simulators to "test and see" how 
the page responds, there are toolkits with pre-packaged responsive 
designed widgets that authors can use, etc.  Even with all that it is 
still not trivial. 

I could envision a day when authors could be required to do it, whatever 
"it" is.  But today they would throw up their hands and give up until we 
could better articulate what is really needed and how they could verify 
that they are doing it correctly - e..g. testable criteria!   Is there an 
initial example responsive web app that is developed correctly with these 
extended techniques?

When you say: "Authors do not have to code accommodations, but they do 
have to provide an environment that supports them."
I would say it a little differently, more like: "Authors do not have to 
code accommodations, but they do need to provide a web app that responds 
correctly to an environment that supports those assistive technology 
features."
For example, end users would also need the desktop browser to support an 
end-user narrow smartphone mode too, even on wide screen desktop browsers 
with super large (greater than 2X) platform supported font size.  We the 
accessibility community need to define that environment so that browser 
developers can create the support needed for the "narrow view" and the 
associated extensions needed to create the super large font wide view 
environment that the authors need to respond to.  hmm, I think I used the 
word need to many times . . . 

I agree this affects a lot of low vision users.  And from my 
understanding, more than screen reader users.  Not to say that one group 
is bigger or more important than another, or that one need is more 
important than another.  But  to be inclusive of all needs of all groups 
is our goal. 

p.s. 
what is LP?  as used in: "and the ability to operate without toolbars that 
take up too much space in LP." 
        is LP short for "Long Play" - as in big desktop displays?
___________________________________________
Regards,
Phill Jenkins, 
Senior Engineer
IBM Accessibility




From:   Wayne Dick <waynedick@knowbility.org>
To:     Phill Jenkins/Austin/IBM@IBMUS
Cc:     WAI Interest Group <w3c-wai-ig@w3.org>
Date:   01/18/2016 05:58 PM
Subject:        Re: Allowing font size changes



I have stayed out of this to see our best thinkers address this problem.

Here is where I come down. Intelligent enlargement is the responsibility 
of authors, user agents and operating systems.  The full capability and 
granularity of  CSS 3 is really the level of access needed. It is there to 
serve other design needs, why not do it to help people with disabilities.

Authors are responsible for arranging pages so that they can linearize to 
fit one column so that the full width of the viewport can be used for 
enlargement.  Responsive design already does this for small screens. It is 
trivial to extend this authoring technique to large screens with very 
large print. Many pages already do this; most will in the future; and it 
follows that if this can be done to accommodate small screened mobile 
devices a few more media query cases can be added to include very large 
font.  The answer is quite simply, yes, authors now have the techniques 
needed to create accessible page formatting. They should be required to 
use it. The real guideline here is to get out of the way of assistive 
technologies like assistive style sheets. Authors do not have to code 
accommodations, but they do have to provide an an environment that 
supports them.

The UA must be supportive enabling gross parameters like base font 
settings, color settings and maybe even some typographic enhancements like 
letter line and word spacing. But as long as the author does the job, most 
of this can be provided by AT. The main support the UA can provide is with 
large print UA controls, expand/collaps large print menues and the ability 
to operate without toolbars that take up too much space in LP.

The UA should always use operating system preferences when present. But 
these often do not provide sufficient granularity.  For example: What font 
does a UA use for a options setting dialogue? Many browsers use the OS 
fonts sizes and then dialogues are impossible to use. 

The point is this: The OS can forsee the least granularity. The UA can see 
more. Only the author knows the structure of content. Thus, responsibility 
falls most heavily on the author, then on the UA and finally on the OS.

Wayne

On Mon, Jan 18, 2016 at 2:34 PM, Phill Jenkins <pjenkins@us.ibm.com> 
wrote:
> 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> 
To:        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> 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>
>> *Cc: *Patrick H. Lauke <mailto:redux@splintered.co.uk>;
>> 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>
>>     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> |
>>     https://github.com/patrickhlauke
>>     http://flickr.com/photos/redux/ | 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 - - - Find more at http://yandex.com
Received on Tuesday, 19 January 2016 02:04:05 UTC

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