Re: Allowing font size changes

Hi All,

Here is something practical you can use today.  Enlargement should go up to
about 7 or 8x to be realistic.  The browsers go to about 4x.  Here is how
to fix that in Firefox.

There is a address about:config you insert as the url. Now there are two
parameters of interest.


The first has default settings of:
The second is set to:

I reset them to
and 700

about:config warns you about violating the warranty but I ignore it.
You can even read legal disclaimers with at juice.


On Wed, Jan 20, 2016 at 11:11 PM, Srinivasu Chakravarthula <> wrote:

> Indeed great discussion. I agree with Phil that it's "user agent" and
> "users" responsibility to know how to set the font size they want. However,
> my comment for original question is that:
> 1. It's definitely not a essential requirement for author to provide such
> buttons but depends on your target audience. If target users are of people
> those may not have reasonable knowledge of options on browsers / OS, then
> it may be a good idea to provide such buttons. I think there would be many
> users who just know the address bar and content window.. they may not even
> know what is title bar...
> 2. For mobile devices, I recommend either not to have or provide option
> for users to hide the tool bar if they wish to do so, because firstly the
> screen size is small so it's ideal that users get to see primary content of
> the site than enhanced tools.
> BTW, I'm a person with low vision, but I have never used font size buttons
> provided by authors as I'm aware of browser / OS options... But yes, users
> are not same!
> Best,
> Srini
> Regards,
> Srinivasu Chakravarthula - Twitter:
> Website:
> Let's create an inclusive web!
> Sr. Accessibility Consultant, Deque
> Hon. Joint Secretary, The National Association for the Blind, Karnataka
> Branch
> On Thu, Jan 21, 2016 at 2:22 AM, Phill Jenkins <>
> wrote:
>> yes good discussion,
>> and please make sure the task force captures all this in their documents,
>> for example in the user needs document -
>> **
>> <>.
>> Jon, you, Alan, and others are in the task force too, so that is good.
>> Is anyone a "responsive" front-end developer?  FOr example, they are
>> really familiar with the 3 breakpoints they use in designing desired
>> re-flow behavior and when to switch from complex grid layouts to single
>> columns card views.
>> I think the task force needs a rep from
>>         1. Freedom Scientific's MAGic and
>>         2. Ai Squared's ZoomText
>>         3. Firefox, Safari, Chrome, and Edge
>> on the task force too since MAGic and Zomtext are so popular with many
>> Low Vision users working with the top desktop and mobile browsers..
>> W3C WAI Low Vision Task Force
>> Current Participants
>> ____________________________________________
>> Regards,
>> Phill Jenkins,
>> IBM Accessibility
>> From:        Wayne Dick <>
>> To:        Jim Allan <>
>> Cc:        Phill Jenkins/Austin/IBM@IBMUS, Jonathan Avila <
>>>, "" <>
>> Date:        01/20/2016 12:41 PM
>> Subject:        Re: Allowing font size changes
>> ------------------------------
>> This has really been a clarifying discussion.
>> Thank You Oscar for kicking this off.
>> Wayne
>> On Wed, Jan 20, 2016 at 6:46 AM, Jim Allan <**
>> <>> wrote:
>> Phil
>> LP = Large Print
>> On Tue, Jan 19, 2016 at 4:46 PM, Wayne Dick <**
>> <>> wrote:
>> I think it is time to be realistic about the timeline of standards. If we
>> set standards for what is routine today then in 3-5 years when the standard
>> becomes established, the technology we proposed will be obsolete. That is
>> why we can be a little on the edge when it comes to proposed requirements.
>> Today responsive design is a little new, but worked enough to be
>> reliable. In 3-5 years it will be routine, and some better methodology will
>> emerge.  Today we have progressive enhancement – completely established and
>> guaranteed to revert to one column format. Responsive design is moderately
>> new (5 years old) and tested.  We can write requirements today that insist
>> a page must be linearizable to one column to enable limitless text
>> enlargement (level A). We can make a level AA requirement of responsive. It
>> can be done today, and in 3-5 years when the standard is out in the world
>> it will be easy to implement.
>> As far as enlargement is concerned, it should be defined in EMs. One
>> media query case should look for screens with 10-20 EMs. That gives about
>> 12-14 letters per screen. On a 13in screen that translates to 72 point, 1
>> inch letters. If one selects the (word-break, break-word) option entire
>> words stay on the screen even if they break. This is better than
>> magnification that forces the first part of long words to be out of the
>> visual space once the person moves right. It is linear. On a 26 inch
>> monitor, 10 EM screen width means 144 point font, and the formatting would
>> be very usable.
>> God is in the details. Conversion to responsive is difficult, but adding
>> a few extra queries for low vision is not. Don’t kid yourself. It isn’t
>> some people who have a hard time with screen magnification, it is almost
>> everyone, like 20 to 1. Having sufficiently large font with word wrapping
>> will change the entire world for people with low vision resulting from
>> reduced visual acuity. It did for me.
>> I have read 10 times as many books since CSS 2 as I did in the preceding
>> 40 years. I could not participate in this discussion without that access.
>> Well-structured content changed my life. After eight years of research I
>> know it will do the same for the overwhelming majority of people with low
>> vision. The question is this. We have the technology to do this for
>> everyone, should we hold it back. Is that ethical?
>> Wayne
>> --
>> Jim Allan, Accessibility Coordinator
>> Texas School for the Blind and Visually Impaired
>> 1100 W. 45th St., Austin, Texas 78756
>> voice *512.206.9315* <512.206.9315>    fax: *512.206.9264* <512.206.9264>
>> ** <>
>> "We shape our tools and thereafter our tools shape us." McLuhan, 1964

Received on Thursday, 21 January 2016 21:20:39 UTC