accessibility – Does animated arrow on link hover violate WCAG 2.2.2 Pause, Stop, Hide?

The part of the animation that starts automatically lasts less than 5 seconds. The part that runs indefinitely is controlled by the user (can be stopped by not hovering). It appears to meet the criteria.

The animation is cool, but is it enhancing the usability of the element? Beyond the WCAG guidelines, it’s important to look at whether an animation might be distracting, which could be an obstacle for users with attention-related disabilities. You might consider a Reduced Motion alternative option for users who prefer it.

accessibility – Does animated arrow on link hover violates WCAG 2.2.2 Pause, Stop, Hide?

The part of the animation that starts automatically lasts less than 5 seconds. The part that runs indefinitely is controlled by the user (can be stopped by not hovering). It appears to meet the criteria.

The animation is cool, but is it enhancing the usability of the element? Beyond the WCAG guidelines, it’s important to look at whether an animation might be distracting, which could be an obstacle for users with attention-related disabilities. You might consider a Reduced Motion alternative option for users who prefer it.

accessibility – Translation of Annual and Monthly pricing as “mo” and “yr”

I’m curious if anyone knows if abbreviating monthly and annual pricing as “../mo” and “../yr” will translate into all other languages? For example, if I display pricing to users as “$220/yr” or “18.33/mo”

Furthermore, I’m wondering if the “/mo” and “/yr” abbreviation is accessible for screen readers?
I’ve seen Apple do this on their website but they use aria-hidden=”true” on this portion of the text.

accessibility – Why is low contrast between active and inactive window title bars considered a good thing?

Microsoft gave some explanation for these changes to Visual Studio in this article:

Visual Studio 11 User Interface Updates Coming in RC (May 2012)

(emphasis mine)

Another area of requested change relating to user interface
controls/chrome has been for us to improve the overall sense of Metro
styling within the themes by drawing our own window chrome. By drawing
our own window chrome we have succeeded in both making more efficient
use of space and in increasing the overall sense of Metro styling.

the article continues…

The custom chrome and line work changes we’ve made together with
reducing the number of default toolbars and toolbar icons combine to
give you three extra visible lines of code in the editor compared to
Visual Studio 10
. As I noted at the beginning of the post the overall
objective behind many of the Visual Studio 11 theme changes is to give
you maximum real-estate for, and ability to focus on, your code.

It looks like Microsoft designed a custom title bar in Visual Studio 2012 to:

  1. Move the “Quick Launch” search bar all the way up to the top of the window, so that users could hide all toolbars and see a few extra lines of code.

  2. Make a more consistent metro theme.

  3. Increase focus on “content” (i.e., code)

Based on the article it seems like the custom, low contrast title bars were Microsoft’s attempt to “get you to focus more on your code” rather than looking at the window chrome.


Issues with Microsoft’s article:

  • If you hide all the toolbars, Visual Studio 2010 and 2013/2015 are very similar in the amount of vertical space you have for your code.

In the newer versions of visual studio, Microsoft made the tabs smaller, but they increased the size of the logo in the upper left, the notification button / indicator is also larger than a standard title bar button in Windows Classic.

For Classic Themes: Visual Studio 2013 and 2015 actually have one less pixel of vertical space than Visual Studio 2010.

(click on the image to enlarge it)

VS2010 vs VS2013 code editor space comparison

For Aero Themes: Visual Studio 2013 and 2015 give you four additional pixels of vertical space. (Default font, the pink line is the top of the i in #include ... in Visual Studio 2010)

(click on the image to enlarge it)
VS2010 vs VS2013 code editor space comparison (aero)

This comparison was done on Windows 7.

In Windows 10 / Visual Studio 2017:

  • Compared to Visual Studio 2010 with Windows 7 Aero, you gain an additional 3 pixels of vertical space for your code.

  • Compared to Visual Studio 2010 Windows 7 Classic you lose 5 pixels of vertical space.

So far no environment has more maximum possible space for code as Windows 7 Classic / Visual Studio 2010, though the difference is negligible (not even enough for a full line of code).

As for “Metro makes it easier to focus on content”:

A) In an article talking about Office 2007 (see below), Microsoft specifically mentioned that “Replacing the Window chrome is a very visible way to differentiate your app and increase branding impact”; it seems like if anything replacing the window chrome would make it so that users are noticing the unique look of your application more than the content.

With custom chrome, the application no longer blends in with the rest of the user’s system (and it will probably only look more foreign later on, because it doesn’t “evolve” when the OS updates).

B) Microsoft made the exact same claim about Windows Aero years ago (Archived: Oct. 2009):

One of Aero’s more visually obvious features is glass window borders, which let you focus on the contents of your open windows. Window behavior has also been redesigned, with subtle animations accompanying the minimizing, maximizing, and repositioning of windows to appear more smooth and effortless.


Office 2007

Joe Castro (Microsoft) wrote an article on the usage of custom window chrome (archived 2019), he mentioned Office 2007.

See excerpt below, he was mostly focusing on the technical side of it in the article, however, he mentions that replacing the window chrome can give your application a distinctive look, though it will require more work to implement standard system features. He specifically mentions Active/Inactive states as something requiring extra work.

It seems that some employees at Microsoft recognized the importance of differentiating between an active and inactive window, though perhaps a more “subtle” difference between active and inactive was preferred in the long run.

Predicting the future is hard – or “How to make some people unhappy,
all of the time”

Ultimately replacing the window chrome is doing the job of the window
manager. Emulating Windows like this has potential to miss behaviors
that your users expect, or not work correctly under some circumstances
(like high-DPI, or under a screen reader). Care should be taken to
ensure that the behaviors your users care about will work correctly
with your replacement.

For example, some of the standard window caption features today are:

  • Left-click on the icon to get the system menu.

  • Double click on the system icon to close the app (Office’s pearl does this as well).

  • Right click in the caption to get the system menu.

  • Double-click the caption to maximize the app.

  • With DWM, change the caption text style when maximized.

  • Change colors based on Active/Inactive states (The colors it uses respect DWM colorization when Aero glass is on, the Theme colors when
    not in Windows Classic, and System colors when in Windows Classic.)

  • It respects system metrics for sizes, and the metrics available for measurement have changed in different versions of Windows (e.g.
    iPaddedBorderWidth was added for Vista).

These are all things that the system no longer does automatically for
you when you use your own chrome. And some of this behavior has
changed in different versions of Windows.

Replacing the Window chrome is a very visible way to differentiate
your app and increase branding impact, but it’s likely that an
implementation will miss some things,
or that future versions of
Windows may change some behaviors making your app look out of place.

This doesn’t mean “don’t do this.” Just that replacing the chrome
should be an informed decision.

Also, user feedback on Office 2013 has shown that low contrast in title bars is not just a hypothetical issue:

And another thing, now that I have to have all of these separate window open, how can I tell which one is selected? Previous Office products had a color change in the bar at the top of the window to show whether that window had the focus. Office 2013 doesn’t seem to have any visible indication. I keep pasting things into the wrong windows.

accessibility – Are social media Apps WCAG Compliant?

I have a use case where I need to show 10 error messages in one modal for a particular functionality if there are any errors.
The current proposal is

  1. To show user which error message user has checked and not upfront using Bold font and different color for unchecked messages.
  2. On the contrary for checked messages it is a normal body text.

Relying only on font weight and color is not a good take on accessibility considered. So how are social or any other platforms handling such a case?
Kindly share the inputs and examples if you have come across.

Does including a Konami-code triggered Easter Egg negatively impact keyboard accessibility?

On an open-source project I’m involved in, one of our devs added a mini-game for April Fools Day, which could be opened and played by pressing the Konami Code sequence on your keyboard (up, up, down, down, left, right, left, right, B, A, enter).

In a GitHub issue, we received a complaint about the game, which included this line:

… but I hope the Codidact team would have the decency to acknowledge that such “easter eggs” can be disastrous to users with mobility impairments who use the keyboard to control the mouse, and promise to not allow such “easter eggs” in the future.

A couple years ago I spent some time using the keyboard and not my mouse, and personally never had a problem with accidentally triggering something with the Konami Code, because it’s not a sequence that – in my experience – is likely to be typed accidentally. It’s hard to get such a specific sequence if you’re not trying.

However, since I’m not an expert on this topic, I figured it’d be worth it to confirm one way or the other: Is having a Konami Code Easter Egg an accessibility problem, from a keyboard-user standpoint?

input fields – Accessibility – SC 1.4.4 – Placeholder text not visible when browser zoom is set to 200%

I have a question regarding SC 1.4.4 Resize Text for Placeholders for inputs. I am not for the design we currently have, but have to work a solution with whatever design I have.

The first row in the table has inputs to filter text in the table. In normal view without zoom, the complete placeholder text is visible. But when we zoom to 200%, the placeholder just shows “Filter” and the remaining text is cut off. My first question is whether this violates 1.4.4?

If so, the solution I recommended is to provide a title attribute for the input field, which is not ideal. It only satisfies people with low vision who can use a mouse to hover. But, users with motor disabilities using keyboard will still not be able to see, even though they can visually see the table and relate the column name with the input.

Is there a better way to address this issue without changing the designs? Attaching a screenshot for your reference.

Table without zoom

Table with Zoom

accessibility – Is it accessible to have lists without a heading, assuming previous lists do?

Assume this HTML structure:

<h2>Our latest News and Events</h2>
<ul>
  <li>news item 1</li>
  <li>news item 2</li>
  <li>news item 3</li>
</ul>
<ul>
  <li>event item 1</li>
  <li>event item 2</li>
</ul>

My question is whether the above structure is accessible and good enough, or whether I should merge the 2 lists into one so it becomes:

<h2>Our latest News and Events</h2>
<ul>
  <li>news item 1</li>
  <li>news item 2</li>
  <li>news item 3</li>
  <li>event item 1</li>
  <li>event item 2</li>
</ul>

Note that in both cases the heading semantically covers all subsequent items (news and events). Also, both cases would have the exact same presentation (i.e there wouldn’t be a visible gap between the 2 lists in the first case).

How to design a form for accessibility using ARIA?

I’m redesigning an application form and want to make sure it is as accessible as possible. I’m not an expert in accessibility by any means, but I am trying to mark up the design for developers to code. Am I using the labels correctly?

  1. Should the box for role="form" aria-label="primary contact" include the Primary Contact and description sentence, or just the entry fields?
  2. The Designated Signee question is dynamic. Selecting Same as Primary Contact results in the fields below being hidden. What is the correct naming convention for the radio group and what should the orange box cover?
  3. Any tips for what I should label the headings "Primary Contact" and "Designated Signee" to make it easier for the developers? Do they need id="xxx" tags?

enter image description here

accessibility – Patterns for adjusting settings which may hinder the user’s ability to adjust that same setting again

This question is about those self-referential settings where the ability of the user to control a device, say:

  • using a mouse cursor, or
  • viewing it on a monitor screen

is itself affected by the setting they’re changing:

  • adjusting the mouse speed, or
  • configuring monitor settings

Consider these predicaments:

  • The user sets their mouse speed too fast that they can’t click anything in order to set the setting back to slow.
  • The user positions their multiple monitors in such a way they can no longer find the window or their cursor so they can’t undo the change.

This class of problem is particularly prevalent in the context of assistive devices, where the user’s interface to a device is inherently limited to begin with.

One UX pattern I’ve seen that addresses this is to apply the change and then start a countdown (say, 10 seconds) that will revert the change when the countdown reaches 0. That is, unless during this countdown phase the user is able to click a certain button, proving that the change is acceptable and they are not in a predicament as described above. Ubuntu uses this UX strategy for monitor and display settings, but I have not come across a name for it.

My question is: Are there other UX strategies for dealing with these self-referential settings which risk putting the user in a pinch?

And have people found the UX pattern described above to be successful, or flawed?

(In case it’s helpful to state, my current concern is indeed an assistive device, and mouse speed is the setting on top of mind.)