search

w3c / wcag21

Repository used during WCAG 2.1 development. New issues, Technique ideas, and comments should be filed at the WCAG repository at https://github.com/w3c/wcag.
https://w3c.github.io/wcag/21/guidelines/
Other
142 stars 55 forks source link

Animation from interactions #18

Closed alastc closed 6 years ago

alastc commented 7 years ago

Current versions of SC and Definitions

SC Shortname

Animation from interactions

SC Text

For motion or scaling animations triggered by a user action that is not an essential part of the action, there is a mechanism for the user to pause, stop or hide the animations while still performing the same action.

Suggestion for Priority Level (A/AA/AAA)

Level AAA.

It extends "Pause, stop hide" (Level A) to cover another scenario. The level AAA is suggested because there is not sufficient research to define what size, length of time or other factors should be tested to draw a line.

Related Glossary additions or changes

Essential (already defined)

(Not used in the AAA version) Significant animation: animation which continues for more than 3 seconds, or is synchronized with a user action (e.g. parallax scrolling effects), and affects more than 1/3 of the viewport.

What Principle and Guideline the SC falls within.

Principle 2, Guideline 2.2.

It applies the same principle as "2.2.2 Pause, Stop, Hide", which is under "Guideline 2.2 Enough Time".

Description

"SC 2.2.2 Pause, Stop, Hide" applies when the web page initiates animation, "Animation from interactions" should apply when an interaction of the user initiates animation unexpectedly.

When users take an action not normally associated with animation but some animation is triggered, it can cause distraction or nausea. For example, if scrolling a page causes elements to move (other than the normal movement associated with scrolling) it can trigger vestibular disorders, causing nausea and headaches. A good overview of vestibular disorders on A List Apart from a web design point of view, and an official organisation.

If backgrounds move at a different rate to foregrounds (often termed "parallax scrolling") that can be a trigger, as are foreground animations of items moving in or out of view, rotating etc.

This interview goes through examples. For more information please consult Evidence and Examples on the Wiki.

A webpage needs to either not use these types of animation, or provide mechanism for the user to turn them off.

There is a new CSS media query to assist with the implementation that has support in Safari, and feature requests in the other browsers.

Benefits

The people who benefit from this SC include those who benefit from "Pause, Stop, Hide", as it adds another situation where animation can be triggered. People with vestibular disorders are added as beneficiaries as they cannot always anticipate when animation happens, and are negatively affected if there is no warning or way of turning off the animations.

Note: The impact can be quite severe, triggering nausea, migraine, and potentially bed rest to recover.

Testability

For each example of animation on a page/view check if:

  1. The animation is triggered by a user-action, and
  2. the animation includes movement that is not essential to the action, and
  3. there is no way of using the webpage without triggering the animation.

If all are true then it fails.

Techniques

Related Information

Articles

Public and Member Comments

Surveys

nattarnoff commented 7 years ago

@mbgower from my anecdata (and I can't stress that enough), including my personal experience, any time frame can trigger sickness. The severity and longevity of the sickness depends on the individual and animation.

I've had .25s animations that cause a 15 second attack and some that have caused a 5 minute attack. I've also had animations that are 3 seconds have no effect or put me down for half an hour. More has to do with the motion type and speed than duration, so we have a lot of variables to contend with.

I'm satisfied with any duration 3 seconds or under until we have more data.

Nat

Sent from my iPhone

On Jan 25, 2017, at 11:26, Laura Carlson notifications@github.com wrote:

Agreed. It is getting wordy.

@patrickhlauke would you be okay leaving out the "persist" part? That could go in the understanding doc. So with @mbgower 's added comma (thanks Mike) we would be back to:

'''Significant animation''': animation which continues for more than 3 seconds, or is synchronized with a user action, and affects more than 1/3 of the viewport.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

patrickhlauke commented 7 years ago

@patrickhlauke would you be okay leaving out the "persist" part? That could go in the understanding doc.

I guess an animation that persists for the duration of the user interaction is, in effect, a case of synchronisation, so yes fine by me, as long as it's mentioned somewhere else

mbgower commented 7 years ago

@nattarnoff, thanks for the info, and apologies if using "vertigo" as a generic descriptive is not good form (let me know about that). Can we get some language in the Understanding about the reasoning behind 3 (or 2) seconds and the need for additional data about triggers? That can help focus discussion once this goes to draft.

nattarnoff commented 7 years ago

I don't think there is anything wrong with using "vertigo" in discussion as long as it doesn't end up in the final docs. While there is a big focus on users with vestibular disorders and other motion sickness related issues, animation also affects screen reader users, low vision users, people with Autism and ADHD, as well as migraine and PTSD sufferers. Each of these folks gets affected differently.

For me it is a combination of vertigo, nausea, headaches, nystagmus, aphasia, and fatigue. The majority of the time a small animation just produces some vertigo I can shake in under a minute, but something like the Mac Pro site with it's spinning and assembling Mac will put me down for half an hour or more with all of these symptoms.

As far as the duration, right now the value is best guess based on non-scientific user feedback. Shorter seems to be better. Prolonged animation is easier for users to be distracted or trigger illness. But not all short animations are created equal. A line has to be drawn somewhere and at this point, without more data, it feels safe to sayt if I activate a control that causes an animation that runs more than 3 seconds, it will likely make me feel some level of illness or pain. If I perform an action (like scrolling) that has an animation tied to it (like parallax) for more than 3 seconds, it will likely make me feel some level of illness or pain.

On a bad day, that duration may be much shorter. Other users with animation sensitivities may find the duration much shorter too. I don't think it is fair to developers to say anything under 1 second, but it isn't fair to users to go over 3 seconds. Ideally, the user should be able to turn them off entirely. But that will take a while before it's common practice.

On Wed, Jan 25, 2017 at 1:16 PM, Mike Gower notifications@github.com wrote:

@nattarnoff https://github.com/nattarnoff, thanks for the info, and apologies if using "vertigo" as a generic descriptive is not good form (let me know about that). Can we get some language in the Understanding about the reasoning behind 3 (or 2) seconds and the need for additional data about triggers. That can help focus discussion once this goes to draft.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/18#issuecomment-275204323, or mute the thread https://github.com/notifications/unsubscribe-auth/AAXI4DG_s2IMQp-AemN-4Hj9ze6p6WVbks5rV598gaJpZM4K2jdW .

mbgower commented 7 years ago

Ideally, the user should be able to turn them off entirely.

Another possible candidate for the use of personalization. At the moment, the draft specs @lseeman has posted in #6 seem wholly focused on cognitive usage. But some ability for the author to designate elements that involve motion could potentially offer an affordance that would enable prevention or modification of animations to be handled with a plug-in user agent, instead of an author-created mechanism.

Shorter seems to be better.

Are there objections to 2 seconds?

lauracarlson commented 7 years ago

@johnfoliot, @DavidMacDonald, and all, Mike is proposing 2 seconds. Can you live with that?

@mbgower can you live with 3 seconds?

mbgower commented 7 years ago

Yes, I can live with 3 seconds.

DavidMacDonald commented 7 years ago

I'd say 3 seconds for this draft... if we are provided new information that is compelling that would put it to 2 seconds for good reason, then we could look at it for the following draft.

lauracarlson commented 7 years ago

Seems we have consensus on:

Significant animation: animation which continues for more than 3 seconds, or is synchronized with a user action, and affects more than 1/3 of the viewport.

Thanks everyone!

Pull request: https://github.com/w3c/wcag21/pull/96/commits/ad8b5f43f707aa58d9257197d33a4b48b035dd0e

lauracarlson commented 7 years ago

Hi all,

In case you are interested discussion continues in the pull request.

Thanks, Laura

awkawk commented 7 years ago

Updated the issue description to reflect the FPWD text and reopening issue.

lauracarlson commented 7 years ago

Article: An Introduction to the Reduced Motion Media Query By Eric Bailey

CharlesBelov commented 7 years ago

This impacts me. I suspect that over 1 second of full-screen scroll does affect me. I know that 0.25 second does not. It's hard to tell where the trigger point is without a series of graduated synchronized tests. That said, once triggered, the effects last for me for up to an hour afterwards.

As to whether setting the limit at 1 second instead of 3 puts an unfair burden on websites:

1) CSS transitions give control over their duration, which means they can be set to 1 second or less. 2) Do you really want your website visitor to wait for more than 1 second while the animation runs? That would make your site seem slow. 3) A full long-document scroll in Safari or TextEdit using the Home or End key lasts less than one second and clearly indicates that scrolling is happening. So, there is an existing use case showing that a scrolling animation need not last more than 1 second.

nattarnoff commented 7 years ago

Hi Charles,

Good point on the Home/End key use. I know this directly affects me and I would love to see a shorter time. Unfortunately, we have very little research yet, so we're trying to get the draft through in a way that can still be seen as an improvement over current state.

On Mon, Mar 27, 2017 at 2:38 PM, Charles Belov notifications@github.com wrote:

This impacts me. I suspect that over 1 second of full-screen scroll does affect me. I know that 0.25 second does not. It's hard to tell without a series of synchronized tests. That said, once triggered, the affects last for me for up to an hour afterwards.

As to whether setting the limit at 1 second instead of 3 puts an unfair burden on websites:

  1. CSS transitions give control over their duration, which means they can be set to 1 second or less.
  2. Do you really want your website to interfere with visitor interaction for more than 1 second? That would make your site seem slow.
  3. A full long-document scroll in Safari or TextEdit using the Home or End key lasts less than one second and clearly indicates that scrolling is happening. So, there is a use case showing that a transition animation need not last more than 1 second.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/18#issuecomment-289562125, or mute the thread https://github.com/notifications/unsubscribe-auth/AAXI4KFS-rIIXVJbCy3Bm2OFKYZ9NqAIks5rqBBJgaJpZM4K2jdW .

CharlesBelov commented 7 years ago

Actually, there's one more as to why 1 second is not a burden:

  1. It doesn't say you can't have a longer animation, only that you must provide a way to defeat it if you do have one.
allanj-uaag commented 7 years ago

If a user has to hunt around for what ever mechanism is provided that seems to defeat the purpose. Or put another way ... can the user find the mechanism in 1 second. A good technique would be to have the ESC key stop whatever.

On Mon, Mar 27, 2017 at 6:38 PM, Charles Belov notifications@github.com wrote:

Actually, there's one more as to why 1 second is not a burden:

  1. It doesn't say you can't have a longer animation, only that you must provide a way to defeat it if you do have one.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/18#issuecomment-289617972, or mute the thread https://github.com/notifications/unsubscribe-auth/AG_WL8LbVR9KATOQhCijq_3r3dw-gMVRks5rqEiDgaJpZM4K2jdW .

-- Jim Allan, Accessibility Coordinator Texas School for the Blind and Visually Impaired 1100 W. 45th St., Austin, Texas 78756 voice 512.206.9315 fax: 512.206.9264 http://www.tsbvi.edu/ "We shape our tools and thereafter our tools shape us." McLuhan, 1964

CharlesBelov commented 7 years ago

Would the ESC key defeat all occurences of the animation? Or would they have to defeat each individual animation as it happens? I would be sick by the time I could respond more than once or twice. And how would site visitors be made aware that they could hit ESC?

My understanding of this requirement - and perhaps it needs to be clearer in the writeup - is that the mechanism that defeats the animation for the site only needs to be activated once, at which point it defeats all further interaction-based animations from that website. This is why it needs to be a visible mechanism.

Or not. If all operating systems support a minimize-animation setting (as Windows, iOS, and macOS already do; I don't know about Android), and all user agents expose this setting to CSS and JavaScript (as I understand Safari already does or will soon do), then all sites would need to do is ensure their JavaScript and CSS query this setting and respond appropriately (not provide interaction animations whenever the browser reports that this setting is set).

nattarnoff commented 7 years ago

There are multiple ways an author could provide controls to stop, pause, or slow animations. Right now, I personally am leaning towards the new prefer-reduced-motion media query that the CSSWG proposed and is shipping in Safari Dev preview (Laura links to a good article on it from Eric Bailey). This means the user sets their preferences at the OS level and never has to hunt.

Ideally over time, I'd like to see browsers know that setting is on and try to fix sites that don't use the media query, but I know that's a long shot.

On Tue, Mar 28, 2017 at 1:56 PM, allanj-uaag notifications@github.com wrote:

If a user has to hunt around for what ever mechanism is provided that seems to defeat the purpose. Or put another way ... can the user find the mechanism in 1 second. A good technique would be to have the ESC key stop whatever.

On Mon, Mar 27, 2017 at 6:38 PM, Charles Belov notifications@github.com wrote:

Actually, there's one more as to why 1 second is not a burden:

  1. It doesn't say you can't have a longer animation, only that you must provide a way to defeat it if you do have one.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/18#issuecomment-289617972, or mute the thread https://github.com/notifications/unsubscribe- auth/AG_WL8LbVR9KATOQhCijq_3r3dw-gMVRks5rqEiDgaJpZM4K2jdW .

-- Jim Allan, Accessibility Coordinator Texas School for the Blind and Visually Impaired 1100 W. 45th St., Austin, Texas 78756 voice 512.206.9315 <(512)%20206-9315> fax: 512.206.9264 <(512)%20206-9264> http://www.tsbvi.edu/ "We shape our tools and thereafter our tools shape us." McLuhan, 1964

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/18#issuecomment-289869846, or mute the thread https://github.com/notifications/unsubscribe-auth/AAXI4LBBPUCTa5bEPld1lk3xYS6DsKhPks5rqVfTgaJpZM4K2jdW .

lauracarlson commented 7 years ago

Microsoft comment on Animation from Interactions #191

Ideas how best to address it?

CharlesBelov commented 7 years ago

Update: I'm finding even a sub-second animation can trigger discomfort in me. Consider a grid of thumbnail images that scale as you cursor over them. The images take up less than 1/10 of the screen each. A 0.3-second ease-in-out changing the scale from 1 to 1.08 on hover and back to 1 on cursor-out is triggering me.

CharlesBelov commented 7 years ago

@mbgower (Jan 16) "how can time be used as a measure to capture failure when the animation 'response' only lasts as long as the user action"

An example would be a jump link at the top of a page that triggers a smooth scroll to content 2/3 of the way down an extremely long page. I've seen one of these that lasted several seconds (and the ill effects lasted for an hour). There was no need for this. 0.25 second to complete would have been plenty to let me know I was scrolling down the page.

Even if the scroll they implemented never caused anyone any distress, it made the site unusable for way too long while it was scrolling. You're going to have a hard time convincing me that any animation in response to a visitor interaction is so critical that it justifies making visitors wait more than a fraction of a second (even once, let alone time and time again on repeat visits or as they navigate through the site) to be able to resume interaction with your site content. I am wondering how even a half-second threshhold requirement can create any kind of burden, let alone a one-second threshhold.

jnurthen commented 7 years ago

Would it be possible to turn off CSS animations at the user agent level - either with a (not yet available) browser preference or by using user style sheets such as the following?

Regards, James

On Mar 30, 2017, 5:30 PM -0700, Charles Belov notifications@github.com, wrote:

Update: I'm finding even a sub-second animation can trigger me. Consider a grid of thumbnail images that scale as you cursor over them. This code is triggering me: img { transform: scale(1); transition: .3s ease-in-out; } — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

CharlesBelov commented 7 years ago

Some browsers do not support user style sheets, and, for those that do, some site visitors do not know how to use them. A browser preference, or having the browser respect the system preference setting, would be ideal.

I just checked on a top-to-bottom scroll in TextEdit on a long page. It took 0.2 seconds (6 NTSC frames) and it was clear that a scroll was happening. Can anyone provide a use case where a 3-second animation, or even a 1-second animation, is needed? I mean, aside from a case where there's a link or button reading "Demonstrate process" or similar cases, which I don't think is covered by this particular issue.

That said, depending on page content, rapid scrolling could cause the appearance of flashing more than 3 times per second. This could happen with website designs that break page content up into alternating light and dark full-width bands, something that seems popular these days.

nattarnoff commented 7 years ago

The ability to override animation at a user level is problematic in that if the author didn't plan for it, then the site may be completely unusable.

On Fri, Mar 31, 2017 at 12:22 PM, Charles Belov notifications@github.com wrote:

Some browsers do not support user style sheets, and some site visitors do not know how to use them. A browser preference, or respecting the system preference setting, would be ideal.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/18#issuecomment-290774821, or mute the thread https://github.com/notifications/unsubscribe-auth/AAXI4H4Src5P8OvJx4x9auQo8QpXgNH9ks5rrTZXgaJpZM4K2jdW .

CharlesBelov commented 7 years ago

Ah, but if I can't turn off animation, the site is already often unusable for me, so I haven't lost anything. The only difference would be that I would feel frustrated rather than ill and frustrated.

But I see what you're saying. If the browser automatically defeats all animation, then both non-essential animation (that covered by this issue) and essential animation (that not covered by this issue) would be affected. So the answer would seem to be that the browser needs to expose the system setting to CSS, JavaScript, Flash, etc., and the authors need to heed that exposed information in order to suppress all non-essential animation.

Until browsers make that information available, though, it seems that all we have is "G186: Using a control in the Web page that stops moving, blinking, or auto-updating content"

Perhaps a solution would be to vary the time limit by level, with the current proposal as level A:

"Significant animation: animation which continues for more than 3 seconds, or is synchronized with a user action (e.g. parallax scrolling effects), and affects more than 1/3 of the viewport."

And the following be level AA:

"Significant animation: animation which continues for more than 0.2 seconds, or is synchronized with a user action (e.g. parallax scrolling effects), and affects more than 1/20 of the viewport."

And the following be level AAA:

"Significant animation: any non-essential animation."

steverep commented 7 years ago

My comment and rewording on pull request #96 was never adopted into this SC so I am copying it here. Note that making this change would address the 2nd point of issue #191 by Microsoft. Here's my original comment:

I really want to see this one go the distance, so forgive my nitpicking:

How about something like this (using brackets for options):

User interactions do not trigger significant animations which are not an essential part of the action, {unless | except where] a mechanism is available to pause, stop, or hide such animations [when performing the same action].

Also, consider defining a user action or interaction to specify not only the inclusion of binary and continuous triggers, but also to clarify the applicability to both the content and the user agent. Putting my extra sneaky hat on, the mechanism cannot be to zoom out until the scroll bar disappears.

lauracarlson commented 7 years ago

Public and Member Comments:

DavidMacDonald commented 7 years ago

WebAim Feedback pointed out that we have an OR statement in the definition which negates the 3 second threshold. Here's a proposed revision:

Significant animation: animation which continues for more than 3 seconds, affects more than 1/3 of the viewport and may or may not be synchronized with a user action. (e.g. parallax scrolling effects)

lauracarlson commented 7 years ago

Thank you, @DavidMacDonald !

Does anyone have ideas for improvement?

Significant animation: animation which continues for more than 3 seconds, affects more than 1/3 of the viewport and may or may not be synchronized with a user action. (e.g. parallax scrolling effects)

I wonder do we need 2 examples: one for synchronized and one for not synchronized? If so, ideas for a second example?

steverep commented 7 years ago

If it may or may not be synchronized with a user action, then why does that even need to be part of the definition? I like the idea of including a synchronized action and a single event driven one.

I wonder if requiring 3 seconds misses some common examples that could cause problems for folks with vestibular issues though. For example, take a look at this page which causes relative scrolling when navigation items are clicked (e.g. try clicking "Key Organizations"). If the intent of the SC is to prevent stuff like that, then there needs to be an "or" statement for unexpected relative motion when requiring 3 seconds.

alastc commented 7 years ago

The synchronized bit is needed because there is no minimum / maximum time on parallax scrolling, it depends how long the user does it, but they can't avoid it.

To avoid the may/may not, how about:

animation which affects more than 1/3 of the viewport, and continues for more than 3 seconds or is synchronized with a user action. (e.g. parallax scrolling effects)

I think that means the viewport is always included, and the or is for the 3 seconds / synchronized bit? Or does it mean that it's viewport + 3 seconds, or any size and synchronized?

Damn, pesky English.

lauracarlson commented 7 years ago

Would it be less confusing to split this SC into 2 SCs?

  1. Scope this one just for parallax scrolling: "Synchronized animations from interactions"
  2. Make a new SC: "Unsynchronized animations from interactions"

Thoughts?

lauracarlson commented 7 years ago

Denis Boudreau's blog post How Current Design Trends Affect Web Accessibility includes a section on Parallax Scrolling. His CSUN 2017 presentation (PDF) is also available.

allanj-uaag commented 7 years ago

Does level of transparency of images effect parallax issues?

CharlesBelov commented 7 years ago

Partial transparency bothers me in general for other reasons. While I imagine it would make parallax worse, I have not noticed any sites that use transparency with parallax.

Full opacity does not relieve the parallax issue for me.

Full background transparency definitely does bother me. I encountered a site that ran a looping video behind static text and this triggered the ill effects.

DavidMacDonald commented 7 years ago

This SC needs a manager

lauracarlson commented 7 years ago

Hi @DavidMacDonald ,

@dboudreau kindly agreed to manage this SC. Thanks again, Denis!

However, don't see Denis' name in the assignee list. I suspect @joshueoconnor @awkawk or @michael-n-cooper have the powers to add him.

alastc commented 7 years ago

Note that Webkit has recently implemented a preference (with media query to access) for reduced motion: https://webkit.org/blog/7551/responsive-design-for-motion/

mgifford commented 7 years ago

We've got a few issues that highlight this problem in #Drupal and would love a WCAG 2.1 model to follow https://www.drupal.org/project/issues/search?issue_tags=VIMS

Thanks for the heads up @DavidMacDonald

dboudreau commented 7 years ago

(Slowly) catching up to this SC. Will get in touch with @DavidMacDonald soon.

Hi @dboudreau Probably best to talk to Andrew or Michael in terms of admin rights etc... I'm just another worker bee around here:)

lauracarlson commented 7 years ago

Browser bugs filed by @cookiecrook to add support for CSS prefers-reduced-motion media feature:

DavidMacDonald commented 7 years ago

Hi @dboudreau Probably best to talk to Andrew or Michael or Joshue in terms of admin rights etc... I'm just another worker bee around here:)

alastc commented 6 years ago

Comment from Rachel Nabors: https://twitter.com/rachelnabors/status/892782753783074818

More research needed before including this seems to be the theme. Is there anyone at the larger companies who can or would do research in this area? (e.g. Microsoft, @alexswli, Google) any contacts in the research areas?)

DavidMacDonald commented 6 years ago

More research needed before including this seems to be the theme.

I'm in agreement with this...

General acceptance that motion can cause trouble ..."Significant" is hard to test... it's a Big requirement on modern animated web... minimal research available on triggering characteristics such as length of time and angle of exposure, speed of animation, provocation, time of day, etc.) Large discussion ongoing about the size of the animation on the screen ... It appears every user with Vestibular disabilities is unique and its hard to nail down a group of provocative actions that would significantly address a lot of the issues without significant impact on design.

Given the level of impact on the modern web and the above considerations, I'd say punt it, unless someone can come up with a significant compelling argument for a limited list of actionable, testable, achievable things for authors to avoid doing.

alastc commented 6 years ago

Let's break this into two streams:

  1. Longer term: Yes, more research is needed. Who has contacts in organisations which could make progress in this area? Is there a good lead person? I'm not affected by vestibular disorders or an expert in animation, I just tried to point out the gap.

  2. Short term: Is there anything we can be confident in applying in guidelines now?

Whilst I think everyone would agree with Rachel Nabor's main point (of having a strong research backing up guidelines), there are some differences between specs for CSS/HTML/JS and accessibility guidelines. The scope of HTML (etc) is to "dictate how people BUILD THE WEB...", but accessibility guidelines encourage/discourage particular ways of doing it.

In CSS if you spec a property that people start using, it is really hard to change it later. In the guidelines you can start with a narrow scope and then widen it later (in 2.2., 3.0 etc).

The risks in new SCs are whether it covers enough to be useful (doesn't provide enough benefit), or covers things that are not useful (costs too much for little benefit).

The one that stands out as an obvious first step is parallax scrolling, i.e. ensuring people can avoid it somehow. I get complaints about that from people without (known) vestibular issues in our office.

If that were the specific issue addressed by this initial SC would that mitigate the concerns? It could be expanded on later, widened to cover more cases and for that we'd need to specify time/size/angle whatever the variables need to be.

Longer term we do need more research, someone to lead that aspect, and perhaps a team/task force? That seemed to work for the low-vision/coga/mobile task forces (which started before my time here).

patrickhlauke commented 6 years ago

On 02/08/2017 23:50, Alastair Campbell wrote:

The scope of HTML (etc) is to "dictate how people BUILD THE WEB...", but accessibility guidelines encourage/discourage particular ways of doing it.

Just to pick up on this point: once accessibility guidelines are used as the basis of legislation, though, they do dictate/mandate. A normative SC can't "encourage/discourage"...

P -- Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke http://flickr.com/photos/redux/ | http://redux.deviantart.com twitter: @patrick_h_lauke | skype: patrick_h_lauke

alastc commented 6 years ago

There's a big difference between "use this attribute to do X", and "provide an accessible name via X, Y or Z".

I was trying to draw the difference between specs and guidelines, the way the guidelines are setup you have multiple ways of achieving it, some are easier, therefore "encouraged". Admittedly some methods are banned, but that's rare in the big picture.

DavidMacDonald commented 6 years ago

obvious first step is parallax scrolling, i.e. ensuring people can avoid it somehow.

Do you mean substitute the word parallax for animation?

if not, then that's what the current SC language is, yet it has drawn a pretty strong response, albeit from an animation professional .

alastc commented 6 years ago

Something like:

There is a mechanism to prevent animations triggered by scrolling that are not an essential part of scrolling.

That could probably be simplified/improved, but it would hit the nub of the complaint about parallax. Sufficient techniques would be using the reduce-motion media query, or an on-page mechanism.

I would very much like to know from Rachel whether she would think that is a reasonable course, my gut feeling is that there is a wide variety of things which are problematic for people with vestibular issue, and even the current wording was fairly reasonable (i.e. feasible to do), and didn't cover that much of the issue-space.

I guess another option would be to put the current wording at AAA, as an indicator that it is a known issue whilst the research side is worked on.

cookiecrook commented 6 years ago

Consider using animation verbiage from these articles, because it most closely reflects the shared vocabulary of the designers and UI implementors you are trying to influence.