RE: Screen Magnification

Ø  GV: Not sure I follow.   How could WCAG speak to these topics across all technologies?   Your comments seem to all be HTML specific?

Ø  What do you propose that would work across technologies and content types?

Gregg, we could handle this in a similar way to SC 4.1.1 which only addresses content that uses markup languages.  We could say something like "when a sequence of linear text can be enlarged up to 200% by reflow without changing its meaning, truncation, or loss of function, such text and containing element need be specified in a way that allows for reflow and enlargement.

This is definitely something the community needs to address.  Consider Silverlight apps that want to enlarge text with the Windows OS settings without browser zoom or native iOS apps that want to respond to the larger text option in iOS.  We need to frame this is a way that will possibly allow enlargement without zoom up to a point that is feasible for the layout of an app.  Basically increase the size up to 200% when possible by lessening the whitespace within the app while permitting reflow and without causing truncation.

There is nothing more frustrating to a person with low vision to find an mobile app such as Lync that has lots of extra white space and padding but very tiny text.  There is plenty of room for the text to be bigger even at a normal reading level which would allow use of the app without assistive technology zoom or perhaps even without larger text but the app chooses to use white space and padding as a design plus.  While whitespace and padding may be good for some users such as those with some cognitive disabilities I'd prefer less whitespace and padding with normal to larger text.  This problem occurs in the user interface with standard controls as well as a chat interface where text in a message reflows but cannot be enlarged by the larger text feature in the mobile platform.  In the chat interface there is already a vertical scrolling viewport - so allowing/requiring larger text would not break the layout.  This topic is one that the mobile accessibility task force is trying to find the right wording to create techniques for.

Jonathan

--
Jonathan Avila
Chief Accessibility Officer
SSB BART Group
jon.avila@ssbbartgroup.com<mailto:jon.avila@ssbbartgroup.com>
Phone 703.637.8957
Follow us: Facebook<http://www.facebook.com/#!/ssbbartgroup> | Twitter<http://twitter.com/#!/SSBBARTGroup> | LinkedIn<http://www.linkedin.com/company/355266?trk=tyah> | Blog<http://www.ssbbartgroup.com/blog> | Newsletter<http://eepurl.com/O5DP>

From: Gregg Vanderheiden [mailto:gregg@raisingthefloor.org]
Sent: Tuesday, June 23, 2015 3:18 PM
To: Jonathan Avila
Cc: IG - WAI Interest Group List list
Subject: Re: Screen Magnification



On Jun 23, 2015, at 6:15 AM, Jonathan Avila <jon.avila@ssbbartgroup.com<mailto:jon.avila@ssbbartgroup.com>> wrote:

> I think that WCAG does all it can do

I'm not sure I agree. WCAG allows for fixed sized containers and text and fixed position content.   It's unclear with fixed sizes how user agents would know where to break and reflow while still keeping the visual quality of the page similar to what it looked like.  If pages used percentages and em/rem I'd assume it would be easier for the browser to reflow the content.

GV: Not sure I follow.   How could WCAG speak to these topics across all technologies?   Your comments seem to all be HTML specific?

What do you propose that would work across technologies and content types?



While some users may want the text to be different - I want to preserve many of the visuals of the page.

I've been pleased that desktop browsers are using the zoom to change the viewport size and thus trigger responsive pages to respond on zoom.

Agree.  Very nice to see.



Jon

On Jun 23, 2015, at 12:57 AM, Gregg Vanderheiden <gregg@raisingthefloor.org<mailto:gregg@raisingthefloor.org>> wrote:
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<mailto:gregg@raisingthefloor.org>



On Jun 22, 2015, at 7:27 PM, Phill Jenkins <pjenkins@us.ibm.com<mailto: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

UAAG 2.0 latest draft http://w3c.github.io/UAAG/UAAG20/
 ____________________________________________
Regards,
Phill Jenkins,
IBM Accessibility