Re: Screen Magnification

Hi Phil and all,

Phill Jenkins <pjenkins@us.ibm.com> wrote [1]:
"...what requirements (if any) are being suggested that authors and
page developer can always do...?

Gregg's suggestion [2]:
"Authors must/shall not prevent user agents from reflowing “running
text” in their content (text that is meant to be read as a linear
narrative - and where text position does not convey meaning)." That is
the text that Gregg and I were wordsmithing...trying to find a more
appropriate phrase than "running text".

Phill Jenkins <pjenkins@us.ibm.com> wrote [1]:
"...Any advisory technique that could be submitted?..."

A number of techniques already exist for 1.4.4 [3]. However, quite a
few advisory techniques indicate "future link." [4] Including "Using
page-percent for container sizes (future link)." That may be along the
lines of what Jonathan suggested regarding percentages and em/rem [5].
Or maybe a technique on fluid grids [6] or em based media queries
could help? [7] A "Document a series of techniques about CSS media
queries and layout module to provide more flexible layout mechanisms
that meet WCAG more elegantly" has already been suggested in Row 20 of
the first table on the "Post WCAG 2 Issues Sorted" page [8].

In any event, I have to agree with Jonathan[5] in that I'm not sure
that WCAG does all it can do, since it currently allows fixed sized
containers and text and fixed position content.

Best Regards,
Laura

[1] https://lists.w3.org/Archives/Public/w3c-wai-ig/2015AprJun/0237.html
[2] https://lists.w3.org/Archives/Public/w3c-wai-ig/2015AprJun/0228.html
[3]
http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-scale.html#visual-audio-contrast-scale-80-head
[4] http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-scale.html#visual-audio-contrast-scale-81-head
[5] https://lists.w3.org/Archives/Public/w3c-wai-ig/2015AprJun/0239.html
[6] http://alistapart.com/article/fluidgrids
[7] http://blog.cloudfour.com/the-ems-have-it-proportional-media-queries-ftw/
[8] https://www.w3.org/WAI/GL/wiki/Post_WCAG_2_Issues_Sorted

On 22 Jun 2015 Phill Jenkins wrote:
>OK, I have to admit that I now lost in this thread.=20
>
>back to the issue:
>
>> I think the hardest part this issue is that
>> the problem can?t be solved by content authors=20
>> (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=20
>> ?  or any content guidelines since=20
>> the author doesn?t have control of many technologies? display.=20
>
> I agree. So what requirements (if any) are being suggested that authors=20
> and page developer can always do?=20
> Can someone tell me what are some examples of how the author or developer=20
> makes it hard or more difficult if they already conform with WCAG 2.0 A=20
> and AA?=20
> For example, is there some additional universal requirement beyond 1.4.1=20
> Resize Text Level AA?=20
> 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=20
> currently doing..=20
>
>> NOTE:  that setting page widths in HTML currently causes text to not
>> reflow (BUT IT DOES NOT HAVE TO).  Browsers could easily have an=20
optional
>> setting that would ignore this markup (at user request) and reflow the=20
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=20
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=20
> 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):=20
> The user can globally set all of the following characteristics of visually =
>
> rendered blocks of text: (Level AA)=20
> Character spacing, choosing from a range with at least 5 values=20
> 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=20
> width of the character commonly accepted as the base character for=20
> calculating kerning in the typography for that language (e.g. zero=20
> character in English).
> UAAG 1.4.4 Configured and Reflowed Text Printing:=20
> The user can print the rendered content, and the following are all true:=20
> (Level AA)=20
> a.      any visual, non-time-based, rendered content can be printed=20
> b.      the user can choose between available printing devices
> c.      the user can have content printed as it is rendered on screen,=20
> reflecting any user scaling, highlighting, and other modifications
> d.      the user can have printed content reflow as if the top-level=20
> viewport had been resized to match the horizontal dimension of the=20
> printing device's printable area
>
> hmm, I think not.  So, we do need a new requirement such as UAAG 1.4.x=20
> "Configure and reflow text for display that overrides author page margins=20
> (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=20
> 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=20
available browser,=20
>> such a requirement would mean that NO Page could use page width ?=20
>> which I think would cause problem in some places
>
> I agree.=20
>
> So now we need to as a group (at least the UAAG 2.0 draft working group=20
> with BOTH browser developers and AT developers) agree on the limits (e.g.=20
> 4X?) of what is the browser and what is the assistive technology's=20
> responsibility - agree?
>
> by the way, from a timing and scope point of view, it is a lot easier to=20
> 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=20
> have already adopted WCAG 2.0.  And, amending 508 Refresh beyond WCAG 2.0=20
> would only directly benefit USA Federal, while improving UAAG 2.0=20
> could/should improve many more browsers and benefit users all around the=20
> world. So, lets lobby the 4 or so browser manufactures: IE/Edge, Chrome,=20
> Firefox, and Safari and the assistive technology manufactures (e.g.=20
> ZoomText, MAGic, etc.) and stop wasting our time on the millions of web=20
> owners, hundreds of countries, regulatory bodies, and enterprises (e..g.=20
> WCAG 2.0).
>
> I welcome your comments and sugestions.
>
> References:
>
> WCAG 2.0 - 1.4.4 Resize text: Except for captions and images of text, text =
>
> can be resized without assistive technology up to 200 percent without loss =
>
> of content or functionality. (Level AA)=20
> http://www.w3.org/TR/WCAG20/#visual-audio-contrast-scale
>
> UAAG 2.0 latest draft http://w3c.github.io/UAAG/UAAG20/
>  =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> Regards,
> Phill Jenkins,=20
> IBM Accessibility

-- 
Laura L. Carlson

Received on Tuesday, 23 June 2015 14:38:10 UTC