Re: Screen Magnification

I think that WCAG does all it can do.

I think the rest is up to AT and user agents.

RE the User agent provision you cited —  I can’t quite tell if that is enough or not.   Not clear from wording. 

gregg

----------------------------------
Gregg Vanderheiden
gregg@raisingthefloor.org




> On Jun 22, 2015, at 7:27 PM, Phill Jenkins <pjenkins@us.ibm.com> wrote:
> 
> OK, I have to admit that I now lost in this thread.   
> 
> back to the issue: 
> 
> > I think the hardest part this issue is that
> > the problem can’t be solved by content authors 
> > (though they can make it easier or more difficult).
> > The readers/browsers have as much or more to do with it. 
> > This is one reason it could not be solved by WCAG 
> > —  or any content guidelines since 
> > the author doesn’t have control of many technologies’ display. 
> 
> I agree. So what requirements (if any) are being suggested that authors and page developer can always do?   
> Can someone tell me what are some examples of how the author or developer makes it hard or more difficult if they already conform with WCAG 2.0 A and AA? 
> For example, is there some additional universal requirement beyond 1.4.1 Resize Text Level AA?   
> Any advisory technique that could be submitted?  most all are welcome. 
> 
> Seems that this thread is really trying to or should be trying to describe what the browser +/- AT can or should be doing, and perhaps isn't currently doing.. 
> 
> > NOTE:  that setting page widths in HTML currently causes text to not
> > reflow (BUT IT DOES NOT HAVE TO).  Browsers could easily have an optional
> > setting that would ignore this markup (at user request) and reflow the page.
> > Thus, including page width (where the author thought it important for
> > most users) would NOT be a violation of the guideline IF BROWSERS had such a
> > setting to allow it to be overridden by users who need it. 
> 
> OK, this "ignore page width" requirement sounds like a new UAAG requirement for discussion - correct? 
> 
> or is it already addressed by UAAG 1.4.3 and UAAG 1.4.4? 
> 
> UAAG 1.4.3 Blocks of text (Globally):
> The user can globally <http://www.w3.org/TR/UAAG20/#def-global-configuration> set all of the following characteristics of visually rendered blocks of text <http://www.w3.org/TR/UAAG20/#def-blocks-of-text>: (Level AA)
> 
> Character spacing, choosing from a range with at least 5 values
> Justification (left or right, including turning off full justification)
> Margins around blocks of text
> Note: For the purposes of UAAG 2.0, the base character width is the font width of the character commonly accepted as the base character for calculating kerning in the typography for that language (e.g. zero character in English).
>  <>UAAG 1.4.4 Configured and Reflowed Text Printing:
> 
> The user can print the rendered content <http://www.w3.org/TR/UAAG20/#def-rendered-content>, and the following are all true: (Level AA) 
> a.        any visual, non-time-based, rendered content can be printed 
> b.        the user can choose between available printing devices <http://www.w3.org/TR/UAAG20/#def-printing-devices> 
> c.        the user can have content printed as it is rendered on screen, reflecting any user scaling, highlighting, and other modifications 
> d.        the user can have printed content reflow as if the top-level viewport had been resized to match the horizontal dimension of the printing device's printable area 
> 
> hmm, I think not.  So, we do need a new requirement such as UAAG 1.4.x "Configure and reflow text for display that overrides author page margins (Level AA)" that would be inserted before the current 1.4.4 for printing  - or an additional bullet to UAAG 1.4.3 that also allows the user to override the maximum width for text blocks, (e.g. set it to 20 charters at 4X and reflow)? 
> 
>  > Without that optional override setting [for page block width] in some available browser, 
> > such a requirement would mean that NO Page could use page width — 
> > which I think would cause problem in some places 
> 
> I agree.   
> 
> So now we need to as a group (at least the UAAG 2.0 draft working group with BOTH browser developers and AT developers) agree on the limits (e.g. 4X?) of what is the browser and what is the assistive technology's responsibility - agree? 
> 
> by the way, from a timing and scope point of view, it is a lot easier to edit UAAG 2.0 now than to edit WCAG 2.0 (actually not possible), or any of the policies that countries, regulatory bodies, and enterprises have that have already adopted WCAG 2.0.  And, amending 508 Refresh beyond WCAG 2.0 would only directly benefit USA Federal, while improving UAAG 2.0 could/should improve many more browsers and benefit users all around the world. So, lets lobby the 4 or so browser manufactures: IE/Edge, Chrome, Firefox, and Safari and the assistive technology manufactures (e.g. ZoomText, MAGic, etc.) and stop wasting our time on the millions of web owners, hundreds of countries, regulatory bodies, and enterprises (e..g. WCAG 2.0). 
> 
> I welcome your comments and sugestions. 
> 
> References: 
> 
> WCAG 2.0 - 1.4.4 Resize text: Except for captions <http://www.w3.org/TR/WCAG20/#captionsdef> and images of text <http://www.w3.org/TR/WCAG20/#images-of-textdef>, text <http://www.w3.org/TR/WCAG20/#textdef> can be resized without assistive technology <http://www.w3.org/TR/WCAG20/#atdef> up to 200 percent without loss of content or functionality. (Level AA) http://www.w3.org/TR/WCAG20/#visual-audio-contrast-scale <http://www.w3.org/TR/WCAG20/#visual-audio-contrast-scale> 
> 
> UAAG 2.0 latest draft http://w3c.github.io/UAAG/UAAG20/ <http://w3c.github.io/UAAG/UAAG20/> 
>  ____________________________________________
> Regards,
> Phill Jenkins, 
> IBM Accessibility
>