WCAG 2.1 Feedback from RNIB

WCAG 2.1 Feedback from RNIB

General comment across many of the criteria
We feel that for a lot of new guidelines and their success criteria, testing has not been fully thought through and this presents difficulties for both the developers and the testers. More clarity on this is needed as well as provision of supporting material and tools.

1.3.4 Identify Common Purpose
Level: AA

In other words: What a control does.
We agree with the principle. It will be time consuming to check this as we will have to check each button of the page.
https://www.w3.org/TR/WCAG21/#commonpurposes


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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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?

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.


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.

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.

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.

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.

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?

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.

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.

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.

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.


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.

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.

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.



Best,
Andreas

--
Andreas Savva
Lead Accessibility Consultant
RNIB (Royal National Institute of Blind People)
105 Judd Street, London WC1H 9NE

m: 07808847344
e: andreas.savva@rnib.org.uk<mailto:andreas.savva@rnib.org.uk>
w: www.rnib.org.uk

--

Sight loss isn’t black and white - we all see things differently. Explore this spectrum of sight with #HowISee: watch our film at rnib.org.uk/HowISee 

--

 
DISCLAIMER:

 
NOTICE: The information contained in this email and any attachments is confidential and may be privileged.  If you are not the intended recipient you should not use, disclose, distribute or copy any of the content of it or of any attachment; you are requested to notify the sender immediately of your receipt of the email and then to delete it and any attachments from your system.

RNIB endeavours to ensure that emails and any attachments generated by its staff are free from viruses or other contaminants.  However, it cannot accept any responsibility for any  such which are transmitted.

We therefore recommend you scan all attachments.

Please note that the statements and views expressed in this email and any attachments are those of the author and do not necessarily represent those of RNIB.

RNIB Registered Charity Number: 226227

Website: https://www.rnib.org.uk <https://www.rnib.org.uk>