WCAG Proposed New Success Criteria not in any task force
Proposed new Success Criteria for 2.1 not covered by any TF currently
- SC on notification of dynamic changes to content
- Notification of Loading/Busy: SC After initial page load, programmatic notification is provided for each visual indicator that content is loading or the page is busy
- SC on animation caused by scrolling and other unusual triggers
- Live Region Identification
Modification of Current SC
- Modify 4.1.2 duplicate id requirement to "duplicate ids, where the ID is referenced by the attribute(s) of elements and is present in the DOM tree." See thread
Work to support the LVTF on the Horizontal scrolling issue and zoom
List of Proposed Techniques/Failures in WCAG 2.1 not in any Task Force
- Failure of 1.3.1 due to regions of a page which are visually distinct AND which contain distinct groups of content (headers, footers, navigation bars, main content, asides) not being programmatically determinable or identified by text.
- Failure of 4.1.2 due to not providing accessibility supported notification of change to a shopping component See rationale here
- consider 'ranking' Success Techniques (poor, good, better, best) as a way of encouraging best practices
Clarifications and/or Conformance requirements
- Clarify that "Full Page" includes each view (this should be done to the current WCAG) See issue 197
- Ensure that mechanisms to go to conforming alternative are highly discoverable (near top of page) with programmatic notification that the current page is not accessible
boneyard
- Components delivered as part of the initial page load conform with this standard without relying on conforming alternative pages.
- Failure of 4.1.2 due to using a link as a button, without a button role.
- Failure of 2.1.1 due to using a link for a button without trapping spacebar to activate button
- Failures based on the Functional Accessibility Evaluation (FAE) tool from the University of Illinois by Jon Gunderson
- Proposed wording for COGA SC on visually clear interactive controls
- Failure of 2.4.4 due to accessible name of a link not describing the destination of the link. Remove the "Link in context" exception (sentence, paragraph, etc). This context does not show up in links lists. We now have technology that solves the problem (aria-label, aria-labelledby etc.). The exception can be removed by changing the example in the definition of programmatically determined link context and tweaking the definition to talk about the Accessible Name. The language of the SC can remain the same.
- Modify 2.4.4 to include Accessible Name for link destination