The Parallax Effect

I've spent the months of October and November working through a VPAT and learned a lot. 

Getting back into the prep-course material, I'm currently working through the Multi-media and Animation module. While most of the information on captions/transcripts/audio descriptions and audio-video topics don't apply directly to my day-to-day user experience requests, the topic of the parallax effect was interesting enough that I wanted to capture a few notes on it.

Screen shot of a custom control for parallax effects on graphics from WebFlow.com

A colleague recently shared a link to WebFlow.com in reference to designer resources for easily creating web content. This particular link was a scrolling page that illustrated very flashy animations that were available using this service, that you could easily customize if you had their product. It was littered with animations using the parallax effect.

Personally, I feel like the current trend for informational websites being large one-page scrolling image galleries not ideal. This particular page was not only that, but each giant image moved and changed as I scrolled. It was immediately disorienting and gave me a sense of mild panic as if it were some kind of design-related PTSD.

This particular module in the Deque prep-course mentions that specifically as something that should be kept to a minimum and is not something that gives a significant enough value to the experience for the cost of accessibility.

Outside of requiring the same contrast and keyboard accessibility requirements for other content, anything using the parallax effect can potentially decrease usability and negatively impact SEO results.

One of the updates to the iPhone included the parallax effect on the home screen icons when the user tilted the phone. This was later corrected in a future update to allow the user to turn it on or off after complaints were received.



In my opinion, the use of the parallax effect is best avoided completely if the overall goal is to provide a user experience and information accessible to all. I suppose if I were trying to think of a reason where using this effect would be crucial to the user's overall ability to understand what the site was trying to communicate; the only justifiable reason to use it would be related to virtual or augmented reality content. 

I'm having a hard time thinking of anything else with which it would be absolutely crucial to communicate clearly except maybe the dangers of getting vomit on keyboards.

Popular posts from this blog

Practice Site: Keyboard Accessible Tooltip Fail

Image
While reading about keyboard input methods and learning about the success criteria requiring custom keyboard instructions for any custom key commands, one method of accomplishing this was using a tool tip to present the instructions. It mentioned that the tooltip would have to be accessible via keyboard navigation and be able to be read by a screen reader. That reminded me that on my practice site, I spent a significant amount of time creating an example of success criteria for 3.1.3 to provide a definition of an unusual word when the user hovers over the text "affordance" displaying in a tooltip. I did not, however, make this accessible to keyboard-only users or screen readers. Turns out it wasn't even focusable until I gave it a tab index. More investigation into ARIA Practices for 3.24 Tooltip Widget call out specifically that the tooltip container requires role="tooltip" (which I did not have), and the element triggering the tooltip references the tooltip ...
Read more

Boiling the Ocean of Accessibility

Image
It can be daunting to look at an entire platform and be told, "Ok, now make it accessible." You don't need revolutionary planning, or exhaustive sprints to start. Including some accessibility work into regular sprint planning can offset any extra LOE, and you can start adding accessibility requirements right into each ticket. In a blog post for MediSked that I wrote in 2021, " Modular Accessibility for All Users ", I outline some easy ways to incorporate real accessibility into the SDLC, and start making progress to a completely accessible product as a whole. Some of the basics include: Using a third-party library of components that have accessibility built in. (Like Kendo UI for VUE or Deque Code Library )You'll still need to adjust and apply them right, but it will get you most of the way there. Include it in every ticket. Link to specific areas that apply to that ticket so engineers and testers know what to focus on. You can link right to the Deque chec...
Read more

Practice Site: Accessible Forms

Image
Today I finally bit the bullet and focused on creating a page on the practice site that would allow me to practice with form components, and live events based on actions. I have the basics down thanks to a friend of mine who walked me through the tools and resources that would be best for this very specific scenario and wrote the skeleton of the page that I could edit to make more accessible. She recommended using JQuery and JavaScript to avoid requiring a database or AJAX. Thanks to w3school.com for their amazing resources. My goal is to make the form fields clear on each submit, and post the data in a styled way on the page. I'd also like to make each submit speak a "success" message to alert the user of the new content, and of course, add labels to everything. Since this took the entire day, it will have to do for now. Luckily there are built-in focus states for the input and button elements by default. This was a productive day, but I may need to take a walk after ...
Read more