Re: Allowing font size changes

I agree, developers can’t detect AT, they can adjust design based on font-size/zoom level.

—Michiel

> On 28 Jan 2016, at 17:17, Jonathan Avila <jon.avila@ssbbartgroup.com <mailto:jon.avila@ssbbartgroup.com>> wrote:
> 
> Ø  Interesting discussion. It sounds like people want the browser to fulfil a magnification software role for web browser content,
>  
> Browsers need to provide magnification because they can communicate the magnification/zoom level to the page which can then respond through RWD to meet the user’s needs.  The browser is also aware of the content in the page and can make changes based on that.  Magnification outside of the browser typically just magnifies a window, lense, or full screen and generally doesn’t communicate with the browser or page.  Magnification at the OS level is often blurry or pixelated – for example, Apple’s magnification IMO is not clear especially on OS X El Capitan.    However, I would draw a line between browser magnification as an accessibility feature and platform level magnification as an assistive technology.   But there are limits the level of magnification that a browser may support because it is not designed to be an assistive technology.  I’m not sure what that level is but I would suspect it would be different than a platform magnifier.
>  
> Jonathan
>  
> -- 
> Jonathan Avila
> Chief Accessibility Officer
> SSB BART Group 
> jon.avila@ssbbartgroup.com <mailto:jon.avila@ssbbartgroup.com>
>  
> 703-637-8957 (o) 
> Follow us: Facebook <http://www.facebook.com/#%21/ssbbartgroup> | Twitter <http://twitter.com/#%21/SSBBARTGroup> | LinkedIn <http://www.linkedin.com/company/355266?trk=tyah> | Blog <http://www.ssbbartgroup.com/blog> | Newsletter <http://eepurl.com/O5DP>
>  
> From: Sean Murphy (seanmmur) [mailto:seanmmur@cisco.com <mailto:seanmmur@cisco.com>] 
> Sent: Wednesday, January 27, 2016 10:07 PM
> To: Wayne Dick; Gregg Vanderheiden
> Cc: Mitchell Evan; Srinivasu Chakravarthula; Erich Manser; Jim Allan; Jonathan Avila; Phill Jenkins; IG - WAI Interest Group List list
> Subject: RE: Allowing font size changes
>  
> Interesting discussion. It sounds like people want the browser to fulfil a magnification software role for web browser content, rather then the person being educated in the use of the tool designed for the purpose of enlarging information on a device or is the magnification software not fulfilling the correct role when people are moving to very large magnification (x4 or higher).
>  
> As the Apple and google platforms all have magnification built into their mobile products. Desktop platforms either have it built in or provide third-party products to provide the ability of large magnification. I not sure if the browser should provide this capability.
>  
>  
>  
> Regards,
> Sean Murphy
> From: Wayne Dick [mailto:waynedick@knowbility.org <mailto:waynedick@knowbility.org>] 
> Sent: Thursday, January 28, 2016 1:46 PM
> To: Gregg Vanderheiden
> Cc: Mitchell Evan; Srinivasu Chakravarthula; Erich Manser; Jim Allan; Jonathan Avila; Phill Jenkins; IG - WAI Interest Group List list
> Subject: Re: Allowing font size changes
>  
> Hi Michell, and thanks Gregg,
> 
> Anyone else with low vision who wants to pitch-in please do. We do not all adapt the same.
> 
> Here is how I operate on a computer:
> . To read blocks of text:  I use 4x to 6x. Depending on the size and importance of the document, I will devote time to convert the content into a form that permits  word wrapping and other style mods.
> . To operate buttons and menus I memorize where the control is located. This is not difficult most of the time, but sometimes I need a zoom.
> . Fixes size dialog boxes are the real hell. I have to use zoom and it is a real mess.
> . Many dialog boxes will include a large font size but keep their original box size. That requires resetting font sizes back to small font, using zoom, and going back to large font for the activities that take 90% of the time.
> 
> There is certainly an advantage to using one AT to do everything, but to date the only reliable packaged AT is zoom.  This is good for spot work, but it really doesn't work for professional reading. Hence, I use a hybrid AT method even though it requires juggling.
> 
> Wayne
>  
>  
> On Sat, Jan 23, 2016 at 1:11 PM, Gregg Vanderheiden <gregg@raisingthefloor.org <mailto:gregg@raisingthefloor.org>> wrote:
> Hi Mitchell,
>  
> RE the question about enlargement beyond 4x in the browser
>  
> Some reasons for this 
>  
> it is much easier than a magnifier
> no panning (very confusing to some) if page is done right
> some people do not have magnifiers 
> some people cannot grok magnifiers
> not always on a computer that has one 
>  
> There is always the question of how they put the URL in there in the first place — but there are solutions (and we have one big one we are working on — GPII) where the person just plugs in a USB and everything is configured for them — or it automatically takes them to a page from which they can navigate to others.  But having the pages be responsive and allow text zooming over 4x  would be needed by many. 
>  
> it is imperative that we remember the range of people who need to be able to use the internet — and it includes many who can barely use technology - and can’t master complicated (but powerful) AT — or even what we think of as simple AT  (but is not really) 
>  
> Gregg
>  
>  
> On Jan 23, 2016, at 2:41 PM, Mitchell Evan <mtchllvn@gmail.com <mailto:mtchllvn@gmail.com>> wrote:
>  
> > 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 <mailto: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 <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 <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 <mailto: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/ <http://twitter.com/CSrinivasu/> 
> Website: http://www.srinivasu.org <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 <mailto: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/ <https://www.w3.org/WAI/GL/low-vision-a11y-tf/> 
> Current Participants https://www.w3.org/2000/09/dbwg/details?group=81151&public=1 <https://www.w3.org/2000/09/dbwg/details?group=81151&public=1>
> ____________________________________________
> Regards,
> Phill Jenkins, 
> IBM Accessibility
> 
> 
> 
> 
> From:        Wayne Dick <waynedick@knowbility.org <mailto:waynedick@knowbility.org>> 
> To:        Jim Allan <jimallan@tsbvi.edu <mailto:jimallan@tsbvi.edu>> 
> Cc:        Phill Jenkins/Austin/IBM@IBMUS, Jonathan Avila <jon.avila@ssbbartgroup.com <mailto:jon.avila@ssbbartgroup.com>>, "w3c-wai-ig@w3.org <mailto:w3c-wai-ig@w3.org>" <w3c-wai-ig@w3.org <mailto: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 <mailto:jimallan@tsbvi.edu>> wrote: 
> Phil 
> LP = Large Print 
> 
> On Tue, Jan 19, 2016 at 4:46 PM, Wayne Dick <waynedick@knowbility.org <mailto: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 <tel:512.206.9315>    fax: 512.206.9264 <tel: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 <mailto:mtchllvn@gmail.com>
> +1 (510) 375-6104 <tel:%2B1%20%28510%29%20375-6104>