Current version of SC and Definitions

• Current version for viewing | Current version for editing
• SC in full draft guideline
• Understanding doc for viewing | Understanding doc for editing | Understanding doc in master

Open issues and Surveys

Open issues: SC Status page

• April 25 2017 Survey
• April 11 2017 Survey
  (Links to surveys require W3C Member access)

Success Criteria (SC) Shortname

Zoom content

SC Text

Content can be displayed at a minimum width of 320 CSS pixels without loss of content or functionality, and without requiring scrolling in the direction of text except for parts of the content which require two-dimensional layout for usage or meaning.

Note: The width of 320 CSS pixels is equivalent to a browser width of 1280 pixels wide at 400% zoom.

Note: Examples of content which require two-dimensional layout are images, maps, diagrams, video, games, presentations, data tables, and interfaces where it is necessary to keep toolbars in view while manipulating content.

Suggested Priority Level

Level AA

Related Glossary additions or changes

None.

What Principle and Guideline the SC falls within.

Principle 1, Guideline 1.4.4 Resize text

Description

Zoom features in browsers make content on the page larger which helps people with mild, moderate and even quite severe vision impairments. A person can make everything bigger or smaller as needed. Zoom is the default method in all desktop browsers to increase the size of content. Mobile browsers (small screen devices) tend to use pinch-zoom, or a text-size setting in the accessibility preferences.

Technologies like HTML/CSS, PDF and ePub have methods of reflowing content to fit the width of the user-agent window. When zooming in on HTML/CSS content, pixels increase in size, so an element that is 200 pixels wide at 200% takes twice the width on screen.

NB: Mobile devices are by necessity more limited in how they can resize content. This success criteria is to ensure the content is capable of resizing to a reasonable degree. In practice people will need to use a device or user-agent capable of reflowing content such as a desktop or laptop computer.

A significant proportion of people with low vision need more than a 200% increase in the size of content. From the Webaim survey 25% of low vision users indicated needing magnification to 400% or more, which is probably more than the total number of screen reader users. (It is 42% for 300% or more).

The impact of horizontal scrolling can increase the effort required to read by 40-100 times, so avoiding scrolling should be the aim whenever feasible.

The size 400% was picked as the largest size a standard website can get to using responsive design. If the user needs to increase content more than 400%, then a complete Linearisation would be necessary which completely overrides the layout of the website.

The testing parameters are more defined than WCAG 2.0's 1.4.4, where the test should start with a browser at 1280px wide, and then zoom in to 400%. In desktop browsers that means your view is then 320px wide, equivalent to a mobile device. Many sites currently cater to that range of sizes, and that number will only increase as more sites update to be mobile friendly. What is not achieved by being mobile-friendly is testing under landscape orientation, rather than assuming a (portrait) mobile device.

It is also possible to meet this success criteria in PDF files by using the reflow feature of Acrobat Reader, which works well on many tagged PDFs with a defined order and structure. ePub files are designed to reflow so should be able to meet this criteria easily.

FAQ

Mobile devices start smaller, how does that work?

The main principle here is that the web content must be capable of resizing, it is not a device-specific issue. The testing procedure is intended to be more specific than the current 1.4.4, starting at 1280px wide and zooming 400%. This works in desktop/laptop browsers.

The whole concept is enabled by media queries, which were designed to enable reformatting for mobile devices. However, the physics of the smaller screens means that expanding text and/or other content is more constrained. The layout method browsers use on small screen devices does not reflow in the same way, it magnifies (e.g. with pinch-zoom) and causes horizontal scrolling regardless of what an author does.

That is one of the reasons to keep 1.4.4 at a lower threshold (200%) without a prohibition on 2D scrolling, there is an applicable SC for mobile. The other reason is that it covers things within the '2D' exception, such as text within data tables.

For content that is of a fixed ratio (video, images etc) they come under the "require two-dimensional layout" exception. In practice they can expand up to the width (and/or height) of the viewport, and be limited to that.

If this is considered an unresolved issue, then we could take the approach of using a minimum content size such as:

Content displays at 320 CSS pixels wide without loss of content or functionality, and without requiring scrolling in the direction of text except for parts of the content which require two-dimensional layout for usage or meaning.

However, that creates more separation from the reason for the SC, and looks more technology focused (although it isn't actually different).

Is the 400% by area or dimension?

As per WCAG 2.0's 1.4.4, it is by dimension. I.e. you zoom 200% and the width is 200% wider (and height 200% taller).

What about sites which bring in external content?

Similar to other SCs, including content from elsewhere is still being displayed in that page therefore under the sites responsibility. There is a responsibility to transform content in an accessible way from ATAG 2.0. In practice, if the pages shows external content, it should at least provide that content the full width of the page at higher zoom levels / smaller screen sizes.

Does this mean sites have to be responsive?

Basically: yes.

Another way of saying that is sites have to adapt to different devices and browsers, or as Andy Clarke put it in 2011:

Web design is responsive design, Responsive Web Design is web design, done right.

The switch to responsive design is like moving from table-based layout to CSS (actually, I think that was harder than responsive design). We've been talking about zoom and responsive design for accessibility since at least 2013, and even then it was apparent that sites were defaulting to responsive when re-designing.

Apart from particular things (covered by the two-dimensional exception) we have not found a reasonable feasibility argument that new sites/content cannot be implemented in a responsive manner.

What happens if sites move/change things at smaller sizes?

So long as the content and functionality is still available that is ok. If some content is hidden behind a show/hide btton, or navigation is moved into a drop-down it is still available. (Like the 'hamburger' icon patter for navigation).

It is possible people might get confused if things move or get hidden, however, the physics demands that something has to give, you cannot make things bigger and fit them in the same space. Also, the people who need it most would typically be zoomed-in when arriving, so may not notice the difference.

However, if content or functionality is removed that would fail this success criteria.

Unresolved issues

• What if the text is already huge?
• What about native text inputs which are only one line, as filling it in will require scrolling.
• A more intuitive method of saying "without requiring scrolling in the direction of text"
• We have two resize SCs at AA now, should we promote 1.4.4 to A?
• Is it ok to have the 1280px starting point in the testability section but not the SC? If not, should we move to saying "content should work at 320 CSS pixels wide".

Testability

1. Display content in a user agent capable of zooming 400% and start with a window width of 1280px at a 100% zoom level.
2. Increase zoom (for all content) to 400%
3. 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.).
4. If horizontal scrolling is present, check that the content causing scrolling would not make sense without the scrolling.

Expected Results

• Check # 3 is true.
• Check # 4 is true.

Techniques

All existing techniques for Proposed New SC: "Size (all content)"

1. G146: Using liquid layout and ''AND'' using measurements that are relative to other measurements in the content by using one or more of the following techniques:
   • C12: Using percent for font sizes (CSS) OR
   • C13: Using named font sizes (CSS) OR
   • C14: Using em units for font sizes (CSS) OR
   • C24: Using percentage values in CSS for container sizes (CSS) OR
   • FLASH33: Using relative values for Flash object dimensions (Flash)
   • SCR34: Calculating size and position in a way that scales with text size (Scripting) OR
2. G206: Providing options within the content to switch to a layout that does not require the user to scroll horizontally to read a line of text

New Techniques

1. Using fluid grids. Ref: fluid grids
2. Using em based media queries. Ref: em based media queries
3. Using responsive images. Ref: HTML picture element and srcset attribute
4. @@ Consider a failure technique on fixed sized containers and fixed position content??
5. @@ Consider a failure technique on "Interfering with a user agent's ability to zoom" i.e., author using: maximum-scale or minimum-scale or user-scalable=no or user-scalable=0 in the meta element ?? @@ Note: In Pinch zoom thread on the WCAG list people did not seem to be in favor of this as a failure.
6. @@ (HTML) Consider failure for preformatted text or excluding this as an exception to no two dimensional scrolling.