Draft Response issue 721
Answers to RNIB issue by issue
1.3.4 Identify Common Purpose
Level: AA In other words: What a control does.
However, it is helpful to have something that identifies the action rather than just the role. The workload required is an issue not just for testers, but also for developers. We think we may see a lot of people failing this if it is AA. There will need to be some education around this for developers and some more support around how this should be tested.
Proposed WG answer
The changes in 1.3.4 make the SC apply only to input controls, and relate only to the expected meaning of the data being input about the user.
1.3.5 Contextual Information
Level: AAA
We strongly support this success criterion as anything that enables better delivery of effective personalization is going to be helpful to many people. We’d like to see some examples of how this personalization would work on individual websites and what the site needs to do to make personalization work effectively. More clarification is needed on what is meant by “publicly available vocabulary”. Some examples of what this means would be useful and clarity around how this vocabulary is going to be defined. Is this something determined by the W3C and utilised by all or will we have independent vocabularies everywhere which would be very challenging indeed and not really realistic? We think there needs to be more work on this. This success criterion also seems quite subjective and hence difficult to test. In addition, there may be parts of websites that, for example, are accessed via a log in (e.g. a medical site with information for Doctors) that has its own specialist vocabulary that is suitable and appropriate for those particular users – who will not be the general public.
Proposed WG answer
The SC has been renamed and is now called Identify Purpose. We will work to clarify your questions in the understanding document.
1.4.10 Reflow
Level: AA
We agree in principle as the current resizing criteria are not quite effective enough and there are people who use more than 200% without magnification (perhaps not as far as 400%). One way to deliver this is responsive design but there is a possibility of failure if content or functionality is removed (https://www.w3.org/WAI/WCAG21/Understanding/21/reflow.html). There need to be good examples here regarding how to deliver this responsively highlighting the importance of not losing content or functionality. In addition, it may not be possible to do this for elements of websites such as videos – there needs to be clarity around how this is addressed.
Proposed WG answer
The Understanding document covers the issue of a potential loss of content in section "What happens if sites move/change things at smaller sizes?" There is no loss in terms of this SC if content is still available, e.g., hidden behind a show/hide button, or navigation is moved into a drop-down it is still available. Videos may either be responsively resized, or not resized, then falling under the exception at the end of the SC text: "..except for parts of the content that require two-dimensional layout for usage or meaning". So we think this issue is sufficiently covered.
1.4.11 Graphics Contrast
Level: AA
We strongly support this however feel the title is a bit ambiguous and needs to clarify that it applies not only to non-text content such as images, icons but also to user interface components.
Proposed WG answer
The SC title has been changed to Non-text contrast to make it clearer that it applies to graphical user interface components as well as to information-carrying graphics.
1.4.12 Text Spacing
Level: AA
We agree with the principle but have concerns that this will be difficult to test and more resources are needed. We are also concerned that this might be difficult to achieve for AA and perhaps should be AAA. We think more resources are needed to test this. There is a bookmarklet available: https://www.w3.org/WAI/GL/wiki/Results_of_Bookmarklet_Tests_for_Issue_78 However, the bookmarklet does not work successfully on all sites (script refuses to load) so other resources will be needed.
Proposed WG answer
The working group has done testing on many sites, and the type of issues found are not particularly difficult to solve.
The testing (and usage by people with low vision) can also be accompllished using the Stylish pluggin (Firefox and Chrome), which does work on sites with a restrictive content-security policy. At least one individual is also planning small test-focused plugins as well.
1.4.13 Content on Hover or Focus
Level: AA
We strongly support this. However, testing will be a manual process and will be an overhead for “on hover” and there needs to be a clear indication of how to test this.
Proposed WG answer
The tests for this SC may be more manual than for some other SC at first, but we expect that additional tooling will be developed. The SC will only apply on web pages with hover content, so will not apply to every page.
2.2.6 Accessible Authentication
Level: A
We strongly support this in principle. However, the implementation is key and case study examples are crucial to ensure that business requirements are catered for, especially as this is single A.
Proposed WG answer
The WG has not been able to reach consensus on this Success Criteria for inclusion in the Candidate Recommendation, so this SC has been removed from the current draft of WCAG 2.1 and deferred to a future version. We will consider your comment in our future work on this SC.
2.2.7 Interruptions (Minimum)
Level: AA
We strongly support this particularly with there being more and more chat bots on sites and requests for feedback. It is important to have more clarification about what is a pass and what is a fail. A list with common “distractions” would be useful. A list of any exceptions, such as time notification, confirmation messages, error messages etc. is also needed. In addition, it is not clear whether users should be able to enable or disable the interruptions as the website loads – and what impact this has on the criterion. For example, a chat can be muted by default and users can choose to enable the sound notification, rather than the other way around. More thought is needed about implementation and how it will work in practice along with the required examples.
Proposed WG answer
The WG has not been able to reach consensus on this Success Criteria for inclusion in the Candidate Recommendation, so this SC has been removed from the current draft of WCAG 2.1 and deferred to a future version. We will consider your comment in our future work on this SC.
2.2.8 Timeouts
Where data can be lost due to user inactivity, users are warned about the estimated length of inactivity that generates the data loss, unless the data is preserved for a minimum of 20 hours of user inactivity.
Level: AAA
We agree with the principle. We have some concerns about the testability.
Proposed WG answer
We agree that this SC is difficult to test, especially the 'unless' condition. We note that same difficulty applies to Success Criterion 2.2.1 Timing Adjustable, which did not prevent that SC to be accepted in WCAG 2.0.
2.2.9 Animation from Interactions
Level: AAA
We agree with the principle. Guidance is needed on how to implement this to ensure it is done well and is accessible and usable. To some extent it is disappointing that this is AAA rather than AA.
Proposed WG response
The Working Group will develop Techniques that show how this SC can be met. While the primary Technique might be a General Technique for authors to avoid implementing parallax scrolling altogether, the Understanding Document http://rawgit.com/w3c/wcag21/master/understanding/21/animation-from-interactions.html already indicates two further Techniques, a General Technique for offering user settings to disable animation, and a CSS Technique for using media queries to prevent animation from interactions.
2.4.11 Character Key Shortcuts
Level: A
We agree with this in principle but think the general text description of this SC is slightly confusing because of the language used. In particular, the last sentence of the paragraph may require some clarification. Although Character keys are described in the glossary, the description is not sufficient. Practically how will someone remap the keys? Is it realistic to expect a basic user to do this?
Proposed WG answer
We will clarify the SC in understanding and develop techniques.
2.4.12 Label in Name
Level: A
We strongly support this in principle. Would this be able to be undertaken by automated testing if included in the software? If so we should ensure that we request that automated testing tools include this. If manual testing is required, this will be time consuming.
Proposed WG answer
This SC seems in principle suitable for inclusion in automatic testing. It is however not in scope of the WCAG Working Group to mandate the inclusion of such a check in vendors' automatic testing tools.
2.5 Guideline Pointer Accessible
Make it easier for users to operate pointer functionality
We are adding this general guideline too as it is a new section. We think it is important to note that the text used to describe this general guideline is insufficient. Just saying ‘make it easier’ is not helpful for testing. Whilst there are more specifics further down in the SC we feel more clarity is needed.
Proposed WG answer
Guideline texts are not supposed to be the basis for testing. They indicate the general concern and indicate the general direction of good practice, so they are unspecific by design. It is up to the text of the SCs that follow to specify how the respective criteria are to be tested (and up to Techniques to specify actual test procedures).
2.5.1 Pointer Gestures
Level: A
We agree with the principle. We are not clear what a ‘path based gesture’ is? Is this clear enough or does it need a glossary link or better description? This seems more applicable on mobile/touch devices. Users must be able to perform touch functions with assistive technology or with one finger. It is not likely websites will have interactions that require multi-touch gestures. Testing would involve trying a multi-touch gesture and checking the same functionality can be achieved with one finger or assistive technology. This is likely to be time-consuming to test.
Proposed WG answer
Path-based gestures are any gestures where the user engages with a screen (e.g. touches or causes a mouse-down), moves the pointer, and then releases the finger or mouse at another location. The WG will still determine whether we need a definition.
There are already web sites with content that require multipoint gestures, e.g. for the two-finger panning of a map.
As to testing content, we expect that there will be techiques that can query web content for event listeners looking for events such as touchstart or touchend to identify pages whether the author has implemented touch gestures. However, looking for the existience of equivalent UI controls may at the time being remain a manual task.
2.5.2 Pointer Cancellation
Level: A
We agree with the principle but think that the text for this SC needs some consideration as the full extent is not very clear. We are concerned about testing and how realistic this will be. In our experience developers are not always consistent with the way they implement controls. However, this is important as although we might not be seeing much of this at the moment, we think we might see this more in the future.
Testing will be time consuming, all interactive elements will have to be checked by touch.
Proposed WG answer
The SC applies to all pointer input, no just touch, so it is not necessarily true that all interactive elements will have to be checked by touch. Automated checking procedures might support testing by looking out for particular event handlers such as touchdown and mousedown.
2.5.3 Target Size
Level: AA 44 by 22 px
We agree with the principle but would like to see what target size is being suggested in practice. It’s also important to assess whether it is reasonable to ask people for this to be single A as there is already a note on here that it is a minimum and it should be larger anyway.
As things stand there is no clear indication on how to test this criterion. All interactive elements will need to have their dimensions tested and this seems a very consuming process.
Proposed WG answer (Detlev)
This SC has been removed from the WCAG 2.1 draft since the WG was not able to reach consensus.
2.5.4 Target Size (Enhanced)
Level: AAA 44 by 44 22 by 22 inline
Again, would like to see what size this is in practice. Should there be an A, AA and AAA for target size or should AA be A and AAA be AA?
Proposed WG answer
We will provide examples in the understanding document.
2.5.5 Concurrent Input Mechanisms
Level: AAA
We agree in principle, but are concerned about the practicalities of testing this. Is there a way of undertaking a generic test of code to check if input modalities are blocked rather than practical testing? It could be very complex to review.
Proposed WG answer
It is unlikely that a generic test will suffice, but we expect that a collection of more specific techniques will address much of the testing.
2.6.1 Motion Actuation
Level A
We agree in principle, but are concerned about the practicalities of testing this. The criterion also could be better worded.
Proposed WG answer
We have renamed the first exception, "Accessibility supported". It now reads "Supported Interface: The motion is used to operate functionality through an accessibility supported interface". If you have other specific suggestions how the SC text could be improved, feel free to comment on the forthcoming Candidate Recommendation of WCAG 2.1.
2.6.2 Orientation
Level AA
We strongly agree with the principle and agree that there are specific exemptions, but good examples of these specifics should be given to ensure that these are not used to avoid compliance.
Proposed WG answer
We agree that examples are helpful. That is why the note already mentions four cases where orientation may be essential. The Understanding text has three examples that show common scenarios in which change of orientation should work. However, examples can never enumerate all cases that may qualify for the essentrial exception. If you have examples that you would like to see included to show cases where exceptions would not qualify as essential, we welcome your suggestions and will extend the Understanding doc accordingly.
3.2.6 Status Changes
Level AA We strongly support this principle and wonder if there has been any consideration about this being single A? An example of adding an item to a shopping basket (where the action triggers a message ‘item added to basket’ which is announced by a screen reader and the user can continue navigating the content) is a good reason as to why this should be single A as well as success notification for forms.
Proposed WG answer
This SC was proposed at AA and the WG has not reached consensus on moving it to a different level.
Other things of Note
We wanted to flag these as we feel they are important issues from the RNIB’s perspective but appreciate it may not be possible to consider all these at this late stage.
Read Only Fields
It is important to make sure that the focus can go to read only fields and enable the content to be read via a screen reader. This is essential for applications that are web-delivered where this is often seen.
Proposed WG answer
This is already covered by WCAG 2.0.
Use of Headings
We would like to see the use of H1 on the page being better defined, specifically that it identifies the main content heading and where its location should be. This can be an issue for example on the Home page where often the logo is used as the H1.
Proposed WG answer
There are various ways out there to use headings. This question has already been addressed in WCAG 2.0, and at that time, the working group made the determination to not require an h1 beyond identifying the semantic structure when available on a page.
We feel that it is beyond the scope of normative success criteria to mandate a particular headings usage pattern. If you have suggestions for a Sufficient or Advisory Technique around the use of h1 headings, feel free to suggest it, preferably at Github https://github.com/w3c/wcag/issues or via the Online submission form https://www.w3.org/WAI/WCAG20/comments/onlineform.
Addition to Error Identification
We strongly support the provision of providing a summary of all error messages at the top of the form as well as inline. In addition, when the user presses submit, the focus should move to a message stating that there are errors on the form. Clarity over what is good practice is needed.
Proposed WG answer
There are various ways of implementing error handling. While the pattern you suggest is a best practice, the WG feels that it is beyond the scope of normative success criteria to mandate a particular usage pattern. If you have suggestions for Sufficient or Advisory Techniques around error handling, feel free to suggest them, preferably at Github https://github.com/w3c/wcag/issues or via the Online submission form https://www.w3.org/WAI/WCAG20/comments/onlineform