WCAG 2.1 SC status


This page contains information about the SC proposals and what issues have been encountered/addressed in the review process. For reference: Success Criteria Requirements

Issue 13 - Minimize user errors

  1. Item 1
    1. Resolved by ....
  2. Item 2
    1. Resolved by ....

Issue 14 - Timeouts

  1. Concern about 24 hour exception period not matching 2.2.1's 20 hour period.
  2. Suggestion that we should have separate SC for a) advance notice and b) 24 hour data retention - the general idea is that both should be always required rather than the latter being an exception for the former.
  3. Concern that the SC should relate to timeouts "encountered by the user" instead of "set by the content"
    1. AWK response that we are re-using text from SC 2.2.1 and the goal there was to only address limits imposed by the author (as these are the limits that the author will have control over)
  4. Connected to 2.2.5(AAA) being moved to AA, although we need to look at possible privacy concerns.

Issue 60 - Target Size

  1. concern about overlapping items creating a smaller target for overlapped item
    1. addressed: this concern and others resulted in a discussion and straw poll about excluding targets in blocks of text or excluding text-based targets in blocks of text. The attendees on the call felt that it was better to exclude all targets in text blocks - resulted in "Inline: The target is in blocks of text." exclusion
  2. impact on native controls? In particular, the native appearance of controls like checkboxes and selects where the target to operate the control is small. This is also an issue for new native controls like the "numeric stepper" control and date controls where the targets are even smaller but there is an alternative way to operate the control (enter the number or date manually in the text field).
  3. what about non-square targets?
  4. What about mobile user agents that don't support this like desktop browsers?
    1. Addressed with exclusion: Cannot be Modified: the target is controlled by the user agent and cannot be modified.
  5. Doesn't the resize content SC address the core issue with this SC proposal?

Issue 69 - Single key shortcut alternative

  1. concern that people may think that we are talking about accesskey even though we are not, perhaps limiting to web apps in some way?
  2. have we considered other keyboards like for CJK?
  3. can this be simplified by making the focus be on using a modifier key rather than not using only character keys?

Issue 77 - Resize content

Updates in the description on github.

  • concern about what constitutes a fixed spoil layout

AC: Have changed the SC text to say "which require two-dimensional layout for usage or meaning", and added examples in the note.

  • What is the role of the UA for web content? Implication for mobile UA
    • web-based email client renders an HTML-based mail message, and that message includes a long horizontal string formatted with whitespace:nowrap, do we _want_ the user agent to strip out the whitespace:nowrap, so that it avoids having the text either truncated or require horizontal scrolling (depending on the hosting user agent)?

AC: If this means things like gmail showing email content from another provider, I'm not sure this SC can solve those responsibility issues, it overlaps with ATAG and UAAG as well. In practical terms the layout should provide 100% width to the external content, but not sure whether or how to include that?

  • Looking at the possibility of 320px as a metric for this... more to come.

AC: This makes sense if we can't include the 1280px in testability and have to put it in the SC text.

  • Should this be somehow based on device independent pixel sizes?

AC: I don't think so, not sure of the question though. It does make use of the concept in practice, but it is not required to outline or test.

  • What if the text is already huge?

AC: A good question, but I haven't found an example of this! If the site provides a mechanism to increase the size 400% then it should be compatible with zoom and should work ok. If they just have one size and it starts huge, then it will be very difficult!

  • question about native controls - does text in a native text input need to conform?

In what situation are native controls "web content"?

  • lack of mention of reflow, yet it seems a prerequisite for achieving this SC

AC: Added to the description (later understanding doc).

  • "scrolling in the direction of text" isn't intuitive

AC: open to suggestions, we used to have "two dimensional scrolling", so it would need to be better than both of those!

  • what happens with 1.4.4? combine?

AWK: TBD, for now we are defining it as an independent SC


Issue 78 - Adapting Text

  1. Scope Concern: Must "technologies being used" be in a SC's text, if that SC has support in 2 technologies? Applicability to mobile, Flash, Java Web Start, etc when technologies don't support. Oracle among others have raised concerns.
    1. May possibly be resolved by including a scoping clause. Laura has asked @awkawk about an escape clause for Flash, and other technologies. No reply to date. The LVTF agreed at its June 17, 2017 meeting to put forth the latest scoping SC text. It is documented in Proposal Q.
  2. Font Bullet Concern: No consensus. The font bullet opens up numerous points of contention, including but not limited to internationalization, testability, and narrow vs wide values.
    1. May possibly be resolved by removing the bullet and dealing with what actually breaks elsewhere. WebAIM supports removing the font bullet. LVTF supports this approach. LVTF RESOLUTION: "removing font family from Adapting Text SC text, because font width is very similar to letter spacing. we will address spacing and font family in the understanding document". - LVTF, April 27, 2017. We haven't found a page yet where the font family cannot be overridden via bookmarklet or user stylesheet or VIP-PDF Reader. Related issues still need to be addressed but just not via a specific bullet point in this SC. Proposed solutions for handling things that break are in the "LVTF Action for SC 78" column of the Adapting text user to content requirements table.
      • Per Wayne: "This concern cannot be resolved by removing the bullet. The LVTF voted for this only to do more research. It is critical for users to be able to change to a font in which all characters can be easily distinguished. This international issue is a non issue. Either font character have almost no variance as in the case of CJK or the distribution is very tight with easy size adjustments."
  3. Color Bullet Concern: The color bullet opens up numerous points of contention, including but not limited to testability and narrow vs wide values.
    1. Like the font bullet issue, possibly resolved by removing the bullet. The related issues still need to be addressed but just not in a specific bullet point in this SC. Proposed solutions for handling things that actually break are in the "LVTF Action for SC 78" column of the Adapting text user to content requirements table.
  4. Create a 2nd SC at AAA Concern: Creating a 2nd Adapting Text SC in 2.1 in addition to the current proposed Level AA one. The 2nd SC would be at AAA and require a mechanism to override formatting.
    1. Unresolved: No consensus. Some people support. Some people do not. Some can live with it either way.
  5. Testing Concern: Do we test all 2.1 SCs individually or in combination with all other 2.1 SCs?
    1. Out of scope. This concern should be considered for all SCs.
  6. Specifying only Paragraphs Concern: Should we reference block-level elements instead of just paragraphs?
    1. This would make testing much more difficult and many existing sites would likely fail as layouts would break.
  7. "adapted" Definition Concern: Do we need the "adapted" definition?
    1. No consensus: Some people want it defined others do not. Greg Lowney objected to not having it defined in the July 6 survey: "Need to link to a glossary entry for "adapted". (I normally refer to formatting being overridden by the client.)". And we have had a comment to remove the definition by Stephen Repsher.