View source for Possible wording from Jason/David for LVTF re: zoom without horizontal scroll

The LVTF is working on one column and zooming SCs. This language came up on a mobile discussion which might be worth looking at.

==SC Shortname==

Content sizing

==SC Text==

SC X.X.X The content of the Web page can be increased the user agent maximum without loss of content or functionality, without bi-directional<sup>2</sup> scrolling, with following the exceptions:
*If the spatial layout of some the content is essential to some of the content's use, that part of the content is exempt. 
*If the user-agent fits the layout to the viewport and does not provide a means of reflowing content, bidirectional scrolling is exempt.

Note: it was  to 300% on first proposal

==Suggested Priority Level==
Level A

==Related Glossary additions or changes==

Definition of essential is already in WCAG.

Essential: if removed, would fundamentally change the information or functionality of the content, and information and functionality cannot be achieved in another way that would conform

 LVTF should decide what the minimum % zoom is, with the notes below in mind. Exception language was borrowed from 1.4.5

==What Principle and Guideline the SC falls within.==

Principle 1, [https://www.w3.org/TR/2008/REC-WCAG20-20081211/#visual-audio-contrast-scale Guideline 1.4.4 Resize text]

This acts as a replacement for 1.4.4, as having a different rule for text (at 200%) would not make sense. If 1.4.4. cannot be replaced, then this SC could be changed to 200%, and would still act as expanding the requirement beyond text. (However, replacing 1.4.4 is the better option!)

==Description==

Simply put: a person can make everything bigger or smaller as needed.

Zoom functions preserve spatial relationships on the page (within certain limits) and all functionality can continues to be available. Zoom works well with developer methodologies like media queries (in HTML and CSS) where the layout can be re-flowed to allow a much larger presentation of content.

===Benefits===

Some people need to increase the size of all interface content in order to perceive information. Although increasing size is most common, some people with tunnel vision and good visual acuity may prefer to decrease the size so they can see more information at a time.

Source: [http://w3c.github.io/low-vision-a11y-tf/requirements.html#size-of-all-elements Accessibility Requirements for People with Low Vision, Section 3.3.5: Size of All Content]

==Testability==
# Display content in a user agent.
# Increase zoom to 300%.
# Check whether all content scales and is perceivable with no loss of content or functionality (e.g. boxes do not overlap, controls are not obscured or separated from their labels, etc.).

Expected Results
* Check #3 is true.

=Workups to this language=
===Version 1===
*SC X.X.X If text is resized up to 200% (or 300, 400, 800%*) without assistive technology, the layout of the Web page ensures that it can be viewed in its entirety without scrolling the viewport horizontally, and without loss of content or functionality, unless a particular presentation of text is essential to the information being conveyed.

===Version 2===

*SC X.X.X If text is resized up to 200% (or 300, 400, 800%?) without assistive technology, the layout of the Web page ensures that it can be viewed in its entirety without scrolling the viewport horizontally, and without loss of content or functionality, where the spatial layout of the content is not essential to its use for the purposes for which users are intended to read or interact with it.

===Version 3===
*SC X.X.X If text is resized up to 300%<sup>1</sup> without assistive technology, the layout of the Web page ensures that it can be viewed in its entirety without bi-directional<sup>2</sup> scrolling, and without loss of content or functionality except for elements of the page where the spatial layout of the content is essential to its use. <br>'''Note''': If a user-agent fits the layout to the viewport and does not provide a means of reflowing content, the author can ignore the requirement to prevent horizontal scrolling.

1) Picking 300% an easily achievable level.<br>
2) Using the LVTF’s term “bi-directional scrolling” as some languages might work the other way around.

NB: The word "text" for the item that is made bigger may not be suitable. A small variation to version 4 was to change it to "content" so that it includes images and other aspects.

=Background=

==David said==
One thing we don't want to do, is to discourage developers from using responsive, because of the great advantage of single column layout for people with Low Vision who are zooming in without the hassle of horizontal scroll ... so it is a fine line balancing act... our message is to developer I think is this:

*We want you to make a responsive design that shifts to single column when zoomed.
*If a user *does* zoom on their "desktop", we don't want them to loose information from the "desktop" view/site. So don't drop content, and if you do, make sure the user can get it back while staying in one column.

Alastair says: <br>
>>In a desktop context, then why not require zooming of 400%?  Now that we have responsive design, that is quite easy, it isn’t nearly the hardship it was before when 200% was settled on. 

David Says:<br>
>>I think also we should study options to increase the zoom requirement. Perhaps the LVTF is doing this???... we need to know the sweet spot between the burden on the developer, (we don't want to break her layout) and the burden on the low vision user who wants to read the content.

Alastair: The LVTF requirements doc talks about sizing text-only as the requirement, but I couldn't find any information on why that is a requirement. Elsewhere I've heard that blurry images can be an issue, but there are other solutions to that. we need to establish this before using 'layout' as the thing that increases rather than 'text sizing'.

==Jason Proposed this wording==
*SC X.X.X If text is resized up to 200% without assistive technology, the layout of the Web page ensures that it can be viewed in its entirety without requiring the user to scroll the viewport horizontally, and without loss of content or functionality.
Note: content or functionality may be shifted to a different Web page upon resizing of text, provided that it remains within a conforming set of Web pages, and that the user can reach it from the page on which text has been resized.


>>Gregg says: again remember that not ALL content can be responsive and still be useful
*a map that flows??
*an excel sheet? 
*tables in general ?   all ?
*an interactive site teaching parabolic trajectories bus showing a cannon that shoots a cannonball across the screen ? 
*angry birds? 
*many games?
*the periodic table?
*the visible horse body  (showing innards) 

>>David suggests: perhaps can address it by using "one column" language or limiting the requirement to Blocks of Text, rather than horizontal scroll??
>>Jonathan brings up the issue of the users monitor. 200% on low res will trip a break point, but the same magnification on a high res might not.<br>
>>Alastair says these examples break down to either data-tables, or pictures. They could be interactive and/or moving pictures, but the commonality is that their 2D-ness is key. I.e. linearising the content (removing the spacial relationships) would undermine the purpose of putting the content/functionality there in the first place.

==Types of zoom==

It is important to understand what types of zoom are available, and difficult to get the terms right! These explanations focus on '''what''' you are increasings/decreasing, rather than '''how''' you do it.

NB: A '''responsive site''' is defined as one using both a meta-viewport setting of 'device-width', and media queries to adapt / re-flow the layout. 

It is difficult (and possibly self-defeating) '''to define a mobile device.''' The key definition is [http://www.quirksmode.org/mobile/viewports2.html what type of viewport a device uses], the layout viewport or the visual viewport. Some (generally small screen 'mobile' devices) use the layout viewport, which means they set the layout when the page loads (media queries are used once, onload, but you can't vary the layout after this point). Some (generally desktop browsers) use the visual viewport which means the screensize is set but the layout can change depending on window size, zoom and media queries.

Zoom types are:

# '''Text sizing''', where ONLY the text size increases (unless the developer uses particular CSS to size other things according to the user’s text size). This is the old/traditional form in desktop browsers that has somewhat fallen out of favour compared to the next one, although still available in some UAs if you know where to look (desktop & mobile). 
# '''Pixel sizing''', where (on a desktop browser) you increase the size of (CSS) pixels and everything gets bigger. If there are media queries in the CSS they are used and the content is reflowed (Desktop on responsive sites only).
# '''Layout sizing''', where the layout can be increased in size but your viewport (screen) doesn't change. You either pinch zoom or magnify in order to make one part of the layout bigger at the cost of not seeing other areas (Mobile and Desktop).

The impact on the possible zoom limit required by WCAG is that:

# Text sizing is difficult to cater for as a developer, in WCAG 2 era before responsive sites it was harder than adding captions for many sites. You can size everything in EMs, which then makes text sizing the same as pixel sizing.
# Pixel sizing is very easy to cater for as user-agents just do it. To prevent horizontal scrolling you need to use a responsive site, which many people do anyway to cater for small screen devices. This is the only method that allows the author/developer to determine what happens when you run out of space (i.e. reflow).
# Layout sizing is impossible to cater for as it automatically creates horizontal scrolling. We could define a minimum font-size to use in general for small screen devices, but I can't see any minimum sizing (without horizontal scrolling) working on mobile devices without user-agent changes.