On accessibility and hover styles

Currently the new design for www.classicpress.net has hover styles that I would describe as “aggressive” or “strong” - they introduce major changes to the appearance of the element when it is hovered. For example:

new-site-hover-styles

Generally this is not something I’m used to seeing. I asked @timkaye about it in Slack, and here is his response:

From a visual perspective, focus and hover essentially cater to people with the same sets of disabilities: poor sight and/or poor peripheral vision. The only real distinction between them is that focus is for those people in that category who use the keyboard, whereas hover is for people who use a mouse.

You can actually see how important hover is just by scrolling to the bottom of the page we have been working on and see the default treatment that the Susty dev has given to hover: he uses a big, fat underline. That’s clearly way more noticeable than the rather pathetic dotted outline that is the browser’s default means of handling focus. (You’ll also notice that he doesn’t always bother to color hyperlinks, which is ironically bad for those with good eyesight! I think he might have done that on purpose to make the point.)

Now you (and @BlueSkyPhoenix) might still find that “jarring” as you have with my and/or Josh’s treatment of the buttons. But your subjective responses really tell me two things: that you are unfamiliar with sites that work well for accessibility purposes, and that Josh’s and/or my treatment actually works. The point is that the styles for hover and focus need to arrest your attention. Otherwise they aren’t doing their job.

This is why mere changes of color aren’t enough. They justaren’t obvious enough to arrest the attention of those who need arresting indicators. Personally, I like Josh’s changes of color, and I don’t find it odd to have both a change of color and something for a11y purposes. But then I am used to using websites that have been specifically designed to work with a11y.

That doesn’t mean, of course, that what I added to Josh’s work is the only means of tackling focus and hover. So I’ll spell out the alternatives. One would be to add an artefact, like an underline or an outline. But neither of those works well with buttons. So this option is out. That leaves us with two alternatives that attempt to use light (or the elimination of light) as the arresting effect:

  1. We can try to mimic outline by having what Michelle aptly calls a glow. I took that effect from the FAQ Concertina plugin that I worked on. Michael, the author of that plugin, was really rigorous about getting the styles to work 100% for a11y. When I first saw the “glow” effect, I too found it jarring. But it now seems normal to me, and I know it does the job. If you are still not convinced, what we could do, as I suggested in the Github issue, would be to make the glow effect smaller. Since the purple and aqua buttons are on a bright white background, that should still work.

  2. We can reverse the color scheme of the button. This works because (a) there must already be a significant contrast between the font and background colors to meet a11y requirements, and (b) swapping the two is very arresting. This is what I have done with the menu items. To be honest, this is generally my preference over the glow effect because I think it’s even more arresting and yet cleaner. But it’s not so straightforward with the purple and aqua buttons because they are placed against a white background. So (even though the button would still have a border) reversing the button font and background colors would risk essentially “losing” the button.

So it seems to me that we need to pick some variant of these two options and then decide whether to keep the button’s change of background color too.

Could a 3rd option be to use a conditional stylesheet that only gets pulled in when screen-readers are active?
Similar as a print stylesheet and an RTL stylesheet for languages like Hebrew and Arabic.

Accessibility is not just for screen readers. To name a couple of other groups, it’s also for people who have slightly impaired eyesight, and who only use a keyboard. That’s my understanding of the intent behind this kind of design, anyway.

While some parts of this design (like the hover effects) look unfamiliar to me, they have the benefit of making it very clear and obvious what I am doing within the UI at any given point in time.

Accessibility is not just for screen readers.

Thank you, I know that.

At the same time I think that the current “visual effects” are targeted at people with impaired vision. Not sure how many of those in fact use screen readers.

I’m just trying to think out of the box a little where we can offer a site looking like a more regular site to people without impairments and use a site looking different for people for whom that might be helpful. Kind of like responsive, but then not based on viewport but based on the visitor’s personal abilities.

If targeting with a conditional stylesheet is not possible, then perhaps via a simple question (with a cookie)?

“Would you like to see the version optimised for people with visual impairments? yes/no plus remember my choice checkbox.”

I don’t think adding more complexity and basically “splitting the design in two” is the right solution. That means more code, and more use cases to test and keep updated later on when we change the design.

I don’t think what’s there is bad, I just wanted to ask about why it’s different from what I’m used to seeing.

I think we can make some of the effects like the glow outline a little bit more subtle, while still achieving their original goal.

I think making the glow more subtle would be helpful.

I like the general idea of reversing to white/color vs. color/white in theory but in the menu it doesn’t fit at all with the aesthetic of the rest of the site. I think if the padding around the menu items wasn’t so large I might feel differently about it, but as it stands now, it seems out of place. It’s just too much white in a space where all around it is color.

What if we instead chose a lighter variant of the color w/ black letters on the hover? For instance, on the hover for the menu items, instead of white, we could choose something like this:

24%20PM

Following on with that, the other buttons would look something like this:

00%20PM

15%20PM

10%20PM

We can also introduce borders or perhaps a reduced version of the glow if that’s also needed, but it appears to me that this might be a nice compromise. Thoughts? @james @timkaye @pieter

3 Likes

Initial thoughts: “everything is too pastel now”.

We have a version of the theme that makes the menu items about the same height as the “get involved” button, and (I think) a more subtle / smaller glow.

I’m going to try to get that up on test.classicpress.net before I go to bed…

2 Likes

Just commenting here to acknowledge that I was pinged. My first thought is similar to James’s, but you can take a look at the revised version I’ve submitted and then work it out between you. I think you’re all attuned to what works well for a11y, and I will be away for the best part of a week, so I’m happy to let you make all the decisions.

2 Likes

test.classicpress.net is updated, we’re getting there! Some key screenshots:

2 Likes

This is much much better!

The gradient of the sub-menu should not be there in my opinion, a solid background color with the subtle border works much better. Also the reduced top/bottom padding makes things look a lot less “clumsy” for lack of a better word.

And for the record: please no pastel colors, we’re not a marshmallow shop

2 Likes