This Wiki page is edited by participants of the WCAG Working Group. It does not necessarily represent consensus and it may have incorrect information or information that is not supported by other Working Group participants, WAI, or W3C. It may also have some very useful information.
Post WCAG 2
Notes about things we might want to do post WCAG 2.0.
(1) Any resource that is not described with metadata must be accessed in order to discover what it is about and how it works and can be accessed. This places a burden on users at selection time, if it is being accessed other than because it is already known to be what the user wants, and so it makes access to the resource less flexible and potentially distracting (as is the case when it is not what the user wants but they have had to retrieve it to discover this).
(2) When the means of accessibility is not a static, conformant page but rather a dynamic compilation of components, as is common with Web 2.0, and as may be achieved by a service that provides resources to match a user's personal needs and preferences (using components that in themselves and in isolation may not be fully conformant), without appropriate metadata, the service agent can not know what components to compile to suit the user. In this case, such a service that potentially provides a higher than usual form of accessibility would be denied. It seems odd to allow this situation to exist.
Change of context after timeout
On 30 September 2010 we discussed the question of a survey that pops up after a delay when a page loads. This was determined to be a failure of 3.2.5 Change on Request and 2.2.4 Interruptions, both AAA. It was considered almost but not quite a failure of 3.2.1 On Focus (which is Level A). The feeling is that it should be a failure at AA, but the SC as they exist didn't cover the situation. Two issues need to be more clearly addressed in the future:
- Should loading of a page be covered by the same provisions that 3.2.5 has for focusing a component?
- A change of context that happens after a timeout creates a greater problem with respect to interruptions and disorientation than a change of context that happens immediately, yet appears to be permitted as a loophole because the wording of the SC is specific to changes that happen immediately.
- Focus order vs programmatically determined reading order vs visual presentation order;
- what keyboard users want/expect from initial focus placement,
- Comment: Promote 2.4.7 from AA to A
- strategies and standards for navigating around a page in ways other than tabbing through all controls
- possible standards and conventions for keyboard access
- User Agent and AT support that is needed to improve this experience for HTML and DHTML
Low Vision Support
- modification of font-family based on element (tag) type,
- enlargement of letter, word and line spacing for text and
- variable enlargement linked to element type.
Adding Dynamic Content
If a user action causes new content to be added, especially outside the user's current viewport, the user needs to know both that the content changed and where the changes are located. This is particularly an issue for blind users when content is added before the current location. Screen reader users read down a page not generally up, so information that is inserted ABOVE the control might be missed. ARIA live regions may be a solution to this in some situations.
Contrast of Hover and Link Text States
As discussed by the working group on February 18, 2014 we want to discuss the possibility of updating the Understanding document to address hover and link text states and whether they are applicable to the color-contrast ratio of the Contrast requirements (1.4.3 and 1.4.7). At the time of Makoto's comment Gregg V. felt that the current language did not cover this circumstance. I, Katie Haritos-Shea, disagree with our response that this is a usability issue and I believe it should fall under 1.4.3/1.4.7 - and I hope that we revisit this issue to update the Understanding document when we can.
Makoto Ueki LC-2893 comment: If a color of link text is changed when a mouse cursor is hovering over a link (by using CSS, a:hover), does the changed color also need to have a sufficient contrast ratio to meet SC 1.4.3 and/or 1.4.6?
Proposed Change: I just want to make sure that the changed color of link text is also required to have a sufficient contrast (or not).
Response (at that time to Makoto): Thank you for your comment. The opinion of the working group is that the color-contrast ratio of the link text when focused or hovered does not need to meet 1.4.3/1.4.6. The goal of the color contrast success criteria is to ensure that content can be read by users, so as long as the links are sufficient contrast when not focused/hovered then they will meet 1.4.3/1.4.6. It is definitely preferred that focused/hovered link text also meet the contrast ratios as this enables users to re-read and verify the target of the link, but this represents more of a usability issue as the user can easily read the link text by removing focus or moving their pointer off the link.
See LC-2893 
Discuss ways of adopting the outputs of the Cognitive TF, having greater interaction/co-ordination between task forces http://www.w3.org/WAI/PF/cognitive-a11y-tf/
Discuss ways of adopting the outputs of the Mobile TF, having greater interaction/co-ordination between task forces http://www.w3.org/WAI/GL/mobile-a11y-tf/
- We will consider including information that more clearly associates failures with the technologies they relate to in future versions of the Techniques document. Issue 2678
- Document a series of techniques about CSS media queries and layout module to provide more flexible layout mechanisms that meet WCAG more elegantly.
- Need techniques about CSS spriting issues. Cynthia has a PFWG action to submit some.
- Sometimes WCAG has a requirement but a "mirror image" requirement that is also an issue isn't as clearly covered. E.g., things that look like headings have to be marked as headings, but things marked as headings don't have to look like headings.
- We will look at issues around form fields. For instance, issue 2766 speaks about a search form field with a submit followed by two radio buttons which further affect the search. This may disproportionately affect non-sighted users.
- Let us work out ways to reduce the confusion about normative/informative. Particularly in relation to Failures/techniques etc. There is lack of understanding that we need to work on fixing. Firstly internally, the WG needs to be clearer on this, so we can then improve our messaging to the public.