Resize content issues review

This is a compilation of issues and comments on Resize content gathered from Github and a working group survey grouped by theme by Alastair Campbell on 26-27th April 2017.

Level (A vs AA) and difficulty

Trace: I don't think this should be at Level A We try to reserve level A to things that cannot be made accessible by any other means if you don't do this.

Webaim: A primary concern is that this Level A success criterion requires 400% text sizing which would invalidate the existing 1.4.4 Level AA success criterion which requires 200% text sizing. This would cause confusion as to why a Level AA SC requires a lower threshold for sizing than a new Level A SC.

Oracle: Having this at level A seems strange when 1.4.4 is at level AA. I would propose adding this at level AA and potentially moving 1.4.4 to level A. Otherwise 1.4.4 needs to be obsoleted.

Kathleen Wahlbin: I think this should be AA not A. Would this replace 1.4.4? At 400%, most sites will go into phone layout if they are responsive. From the user perspective, another issue will be sites that reduce the content shown or remove some functions at 400%. Is this SC implying that all content and features must still be available? I think we should consider reducing this to 200%.

Marc Johlic: With 1.4.4 Resize Text requiring only 200% and only around text and being AA, I'm not sure how we could have this SC be Level A and be at 400% and for all content.

Kim Dirks: Should be AAA for 2.1 so it works better with 2.0. Also this could be virtually impossible to implement for very complex non-responsive sites. Is it realistic to expect authors to totally rebuild complex sites?

Difficulty to meet

Webaim: Meeting this SC will require significant effort by many web authors. Few popular sites tested come close to meeting the 400% sizing threshold. WebAIM suggests a more practical approach – perhaps 200% text sizing with minimal horizontal scrolling (perhaps double the viewport width) at Level A, 400% text sizing with minimal horizontal scrolling (perhaps double the viewport width) at Level AA, and the draft SC as proposed at Level AAA.

Kim Dirks: Should be AAA for 2.1 so it works better with 2.0. Also this could be virtually impossible to implement for very complex non-responsive sites. Is it realistic to expect authors to totally rebuild complex sites?

Kathleen Wahlbin: … Is this SC implying that all content and features must still be available? I think we should consider reducing this to 200%.

Resize text & Reference to current 1.4.4

Webaim: WebAIM suggests a more practical approach – perhaps 200% text sizing with minimal horizontal scrolling (perhaps double the viewport width) at Level A, 400% text sizing with minimal horizontal scrolling (perhaps double the viewport width) at Level AA, and the draft SC as proposed at Level AAA. It is hoped that the working group will also address content loss for true text sizing (i.e., not zooming the page, but only increasing text size) to a reasonable level – perhaps 150%. This and the existing Resize Text SC generally neglect this audience which represents 38% of respondents to the WebAIM Survey of Users with Low Vision.

Marc Johlic: Is the strategy to propose this and then move it to a re-write of 1.4.4? If so, I'm OK with the 400%, and being applicable to all content - but I believe it would still be AA.

Initial response:

There is good evidence that a significant proportion of people with low vision need more than 200%. 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 there is good evidence of need and impact.

The other side of the equation is effort required, which has changed significantly since WCAG 2.0 was written. Compared to the current 1.4.4, we would like to define the testing parameters more closely, such as testing at 1280px wide, and zooming 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. The SC is needed so that people also test their sites under (landscape) zoom conditions, rather than assuming a (portrait) mobile device.

Overall, there are many high-traffic, high profile sites that either meet this criteria, or could meet it without significant investment thanks to changes in development techniques. It is also possible to meet in PDF files by using the reflow feature of Acrobat.

The "fixed spatial layout" does need better definition and examples (in the understanding document), which would include:

Editing / manipulation interfaces, where the content and toolbars need to be visible at the same time.
Images, video, and things which are fixed ratio.
Data tables.

Note: Editing interfaces are currently very difficult to do at higher levels of zoom, if developments make these interfaces more feasible the aim would be to include those within this criteria.

The Resize content SC has a broad exception for content which needs to be two dimensional, such as data tables. Due to the exception it useful to still have an SC like 1.4.4 which requires 200% but no prohibition on scrolling. Personally, I would like to adjust the current 1.4.4 to align with the new SC so that:

Level A: Cater for a 200% increase in text-size and allow horizontal scrolling (current SC at different level).
Level AA: Cater for 400% increase in content without horizontal scrolling, with exception for 2D content (new SC)

For this to work we would need the working group to agree to adjust a current WCAG 2.0 SC. The obvious alternative would be to have both at level AA, but this would look odd to many people.

Using tools that meet it

Trace: This is an example of an SC that we cannot follow ourselves with our own tools. So it should not be a Level A. And it should not be a Level AA either unless and until a) we meet this with all of our web pages and web tools. OR b) for those pages/tools we have no control over - we show that we CAN meet the SC by creating alternate versions of the pages / tool pages that show how it could/should be done.

Initial response

It is not possibly for any one person to say it works for everything, we have to rely on comments and contributions to point out potential issues. The response above talks about the difficulty to meet this SC, it is generally viable, but are there specific things that you know of that do not work for resizing?

Meeting on Mobile devices / formats

Oracle: It is not possible to resize content and avoid horizontal scrolling on mobile devices. Without this ability it would be necessary to add zoom widgets to every page in order to allow content to resize.

Marc Johlic: (I need to understand more about content and no scrolling - for example does this mean I could zoom in on a video player to 400% and not scroll? Would I be expected to be able zoom in just on portions of a video? Similar questions for images. Text can reflow, but I'm not sure how other forms of content can reflow to avoid scrolling)

Initial response

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 "fixed spatial layout" exception. In practice they can expand up to the width (and/or height) of the viewport, and be limited to that.

Other issues

Definition of spacial layout

MS: Better explanation and examples of what content necessitates fixed spatial layout is needed.

TPG: "fixed spacial layout" needs a definition, preferably with examples. While we agree that the SC should not aim to be exhaustive in providing exceptions, our experience is that it is exactly this lack of clarity backed up with real world examples that generates much of the confusion and debate around existing SC.

Kathleen Wahlbin: Need a definition of spatial layout.

Initial response

Ok, we'll work on that.

Misc

MS: It is unclear as to whether the 400% increase is measured by area or dimension. Response: Yes, this is admittedly ambiguous and there would be no harm in clarifying it to mean 4x in each dimension as is the convention across most software zoom features.
MS: The proposal text seems to penalize content that are made to be big by default in order to assist low-vision users. Response: It is a possible problem with using a relative scale, however, it is very difficult to provide a realistic minimum physical size across devices. That type of content is rare (I'm struggling to find any), where it is used is it an alternative to 'normal' size content? In which case it is ok from a compliance point of view.
MS: Note that in many cases the user who needs to zoom the content may also zoom the onscreen keyboard. Response: In this case the keyboard would not be web content, so I'm not sure what the issue is with the SC?
MS: Abstracting this success criterion to the OS level, since the same user who wants to zoom 4x on the content will want to do the same for everything else and that EN 301549 will try to abstract this SC to apply to mobile apps. What does this imply about the magnifier feature from the OS? Is it trying to say that two-dimensional scrolling is ok (and magnifier features are appropriate) once the need goes beyond 4x? Response: No, we simply believe 400% is reasonably achievable by content authors. For users who need more, the linearisation SC is more appropriate.
TPG: Change the word 'resized' in the SC to ‘zoomed’ and be explicit in the description that resize means full page zoom and not text resize, assuming that is the intent. Response: We can do that, although I think it would have to be: "Zoom content", so it lines up with "Resize text". I.e. as an active verb, not an adjective.
TPG: Include word-breaks in the examples for "fixed spacial layout" exceptions. We recommend something to the effect that "Words that exceed the width of the viewport must be hyphenated in user agents that support automatic hyphenation". Response: Assuming this means in the understanding document, we will do so.
TPG: Explicitly specify that a user agent that supports 400% zoom should be used as part of the testing methodology. Optionally note that not all user agents support 400% zoom. Response: Is this for the SC text or is it ok to deal with in the understanding document?

Editorial on the current SC text

i think it's best to deal with editorial issues once the logic/topical/level/other issues about are dealt with, and they may make substantial changes to the SC text.

Kathleen Wahlbin: Minor Editorial Update:

Current SC: Content can be resized to 400% without loss of content or functionality, and without requiring two-dimensional scrolling except for parts of the content where fixed spatial layout is necessary to use or meaning.

Recommended Updated in brackets: Content can be resized to 400% without loss of content or functionality, and without requiring two-dimensional scrolling except for parts of the content where [the] fixed spatial layout is necessary [to use, or to preserve the meaning of the content].

Greg Lowney: "except ..." is a dangling clause, somewhat ambiguous as to which of the two preceding clauses it modifies. Could rewrite to something like "Except for parts of the content where fixed spatial layout is necessary for use or meaning, content can be resized to 400% without loss of content or functionality, and the resized content can be used without requiring two-dimensional scrolling", or to something like "Content can be resized to 400% without loss of content or functionality, and the resized content can be used without requiring two-dimensional scrolling. Exception: two-dimensional scrolling may be required for parts of the content where fixed spatial layout is necessary for use or

Greg Lowney: "two-dimensional scrolling" seems like a problematic term. It doesn't seem to prevent horizontal scrolling of normal English text unless the content is long enough to enable vertical scrolling, yet how can the author predict that when they don't know ahead of time what the resizing ratio nor the viewport dimensions will be? I'd add a suggestion that we use phrasing or define a term more specifically addressing scrolling in the preferred reading direction for the text, e.g. horizontal for left-to-right or right-to-left text, or vertical for top-to-bottom text, or in the non-default scrolling dimension for the user agent.

Bruce Bailey: I think the grammar is a bit off:

...fixed spatial layout is necessary to use or meaning

should be:

...fixed spatial layout is necessary for use or meaning