Re: Allowing font size changes

> Enlargement should go up to about 7 or 8x to be realistic.

I'd like to understand the use cases for text enlargement *in the browser*
beyond 400%. As an author, I've assumed that any users who want text beyond
400% would be enlarging at the operating system level, because they would
need OS interface elements enlarged anyway.

> Do things really have to be so detailed and difficult?

We'll invent solutions that are as simple as possible, but no simpler.

> Is anyone a "responsive" front-end developer?

Raising my hand.

Mitchell Evan

On Thu, Jan 21, 2016, 1:30pm Wayne Dick <waynedick@knowbility.org> wrote:

> 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.
>
> toolkit.zoomManager.zoomValues
> zoom.maxPercent
>
> The first has default settings of:
> .3,.5,.67,.8,.9,.1,1.1,1.2,1.33,1.5,1.7,2,2.4,3
> The second is set to:
> 300
>
> I reset them to
> .67,.8,1,1.25,1.5,1.75,2,2.5,3,3.5,4,5,6,7
> and 700
> resp.
>
> about:config warns you about violating the warranty but I ignore it.
> You can even read legal disclaimers with at juice.
>
> Wayne
>
> On Wed, Jan 20, 2016 at 11:11 PM, Srinivasu Chakravarthula <
> lists@srinivasu.org> 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: http://twitter.com/CSrinivasu/
>> Website: http://www.srinivasu.org
>>
>> 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 <pjenkins@us.ibm.com>
>> wrote:
>>
>>> yes good discussion,
>>> and please make sure the task force captures all this in their
>>> documents,
>>> for example in the user needs document -
>>> *http://w3c.github.io/low-vision-a11y-tf/requirements.html*
>>> <http://w3c.github.io/low-vision-a11y-tf/requirements.html>.
>>>
>>> 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
>>> https://www.w3.org/WAI/GL/low-vision-a11y-tf/
>>> Current Participants
>>> https://www.w3.org/2000/09/dbwg/details?group=81151&public=1
>>> ____________________________________________
>>> Regards,
>>> Phill Jenkins,
>>> IBM Accessibility
>>>
>>>
>>>
>>>
>>> From:        Wayne Dick <waynedick@knowbility.org>
>>> To:        Jim Allan <jimallan@tsbvi.edu>
>>> Cc:        Phill Jenkins/Austin/IBM@IBMUS, Jonathan Avila <
>>> jon.avila@ssbbartgroup.com>, "w3c-wai-ig@w3.org" <w3c-wai-ig@w3.org>
>>> 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 <*jimallan@tsbvi.edu*
>>> <jimallan@tsbvi.edu>> wrote:
>>> Phil
>>> LP = Large Print
>>>
>>> On Tue, Jan 19, 2016 at 4:46 PM, Wayne Dick <*waynedick@knowbility.org*
>>> <waynedick@knowbility.org>> 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>  *http://www.tsbvi.edu/* <http://www.tsbvi.edu/>
>>> "We shape our tools and thereafter our tools shape us." McLuhan, 1964
>>>
>>>
>>>
>>
> --

Mitchell Evan
mtchllvn@gmail.com
+1 (510) 375-6104