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.

Research needed

Jump to: navigation, search

If the working group attempts to create a success criteria (guideline) on a topic but realises there is not enough research, this is where we outline what would be needed.

The research might be to show how much something affects people with disabilities, but more commonly it is to establish where it should apply (or not) to web content. Or both.

Animation from Interactions

The current Animations from Interactions SC was originally put at level A, however, there were justifiable comments that was too sweeping, as small animations (e.g. icons moving) are very unlikely to trigger vestibular symptoms.

Questions to answer

  • At what size do animations start triggering symptoms?
  • How could we define large/small on the web is such a way that works across screen sizes?
  • What animations trigger issues for people with attention impairments?


Visual indicators

The core need is to be able to identify interactive components and know what to do with them, which affects everyone to some degree, but some people with cognitive impairments to a massive degree.

The problem in crafting an SC for this is capture problematic instances, and not capture instances that are not problematic.

Questions to answer

  • What is an appropriate visual indicator? It needs answering for each type of user interface component. (E.g. buttons, links, text inputs etc.)

To provide confidence that the SC works we really need to catalogue plenty of examples. E.g. A list of different UI components and whether they should pass, and whether they do pass according to the SC text. Google doc of examples.


Displaying in-active fields/buttons

From this github issue, 661: > I know one thing that doesn't work well for people with low vision is disabled interface elements. We've exempted them from 1.4.3 contrast, but maybe a better way is to provide an icon for a disabled UI element. > > So it would have to have at least 3:1 contrast OR add an icon to indicate it is disabled.

Questions to answer

What would be an appropriate method of indicating disabled / inactive inputs or controls that does not rely on making them faded out?