Add focus styling to all interactive elements

The twitter argumentation is a little weird, just because someone saying "yes" on twitter :P?

I am not against this, but keep in mind that focus also shows upon clicking of fields. For which we have "focus" styles, we should not overwrite those. I also don't think he suggestion of a red outline, would fit very well with most designs - this includes Bartik. Browser default focus styles, tend to be quite nice - we should replicate some of that.

@mgifford Hehe, oke - yes this looks afwul :P

So could you explain a little why this is not a browser concern? Because that's why we didn't pursue this before, we did take into account "focus" status on buttons but not all elements in the style guide because its largely already done by the browser. Often we can get away with the hover state, in many cases we can't.

The issue of outline:0 in CSS resets was addressed in Drupal 7, and allows browsers to add back in the default link outlines. One issue I can see with continuing to rely on the browser is that the browser's default outlines (often the "dotted lines") have not changed over the years to better accommodate accessibility, and do not accommodate the look and feel of all themes. A theme with a dark background color would potentially render the theme useless to low-vision users because it doesn't provide an adequate color contrast ratio.

Maybe a solution would be to provide a thicker, more contrasting outline to links instead of a link outline and color fill? A 3 - 5 pixel outline with a bright(ish) shade of yellow seems to be the industry standard for accessibility-minded folks. See the Section 508 site and the Youtube video player for examples. Naturally, whatever the solution, the CSS could be easily overridden within the theme to change the color if the default color still doesn't provide the right contrast.

Hi Mike,

Thanks for looking into this more! The Youtube player has been a little weird in Firefox lately, but I managed to get a screenshot of the border I was talking about:

The yellow border like this seems to be a standard default. It probably won't be pretty in every theme, and may not even match color contrast in all themes, but if it was made easily-override-able in the theme, having a default like this could help, and serve as a helpful reminder to themers to include this.

I concur, Mike. As I mentioned in yesterday's comment, this default is weirdly unsatisfactory when it comes to accessibility, specifically for low-vision users or anyone who has a problem with color contrast or very small details.

Furthermore, it really would not be that hard for us to add a default to the Bartik core stylesheet, no? If people don't like the look of it, they can override it, but as was mentioned on Twitter, adding it by default makes it one less thing that can be forgotten for accessibility in constructing a theme (not to put a negative spin on this).

I do think this needs some realignment with visual designers, I think we are working under very different standars as what looks acceptable - none of the designs proposed to me look acceptable. Ideally we choose a toned down browser default style, and apply it elsewhere (e.g. the chrome one).

I'd like to point to the idea that "ohh they can just change it" is not an argument for anything. Bartik is the default we present Drupal with, it is what people out of the box evaluate and if it has elements that would make Drupal not good looking - it will reflect badly upon Drupal, you know Garland did this.

I'd personally prefer to style individual elements with the correct focus styling, the chrome styling gets us really far and its not as obtrusive as is being suggested in this thread. It will not work for all elements (e.g. VT's) and we will need to style those separately, keep in mind we have loads of hover styles that are perfectly transferable to focus.

However I am still not sure we should overwrite default browser styling, aren't people used to that styling? Wouldn't Drupal breaking that styling interfere with a established standard - that people might even have tweaked for contrast? Also the few browsers that don't provide a default focus styling, should get their act together its not Drupal's job to fix these kinds of bugs in firefox.

Inverting colours in what we tended to do whilst I was at Nomensa - e.g. http://www.nomensa.com/blog.

At the very least, the state for :focus should be the same as :hover.

Has the discussion for this problem moved to another issue? My reading of this thread suggests that this patch doesn't correctly fix the problem. Should this issue be in "needs work?"

@mgifford This issue has unfortunately sat here for some time. Is there any chance you can update on what needs to still be completed or the direction to head in? I believe this issue is important :)

Would it help solve the design argument if these focus states were constrained to only when focus is generated via the keyboard and not briefly on click?

I worked with a client who did NOT want focus states when mouse users interacted with elements, so we coded up a small solution that made focus state indicators only appear when accessed via the keyboard. This might be less disruptive to designs while still being useful to the people that this feature would primarily be for.

Seeing focus styles after clicking links is normal behaviour. Clicking moves the focus to the link, in the same way that clicking a text input moves the focus to the input.

Often you don't notice a focus style after a click, because a site has suppressed the default focus style, and used the same style for both :hover, :focus selectors. So first you move your pointer over the link, and get the :hover style. When you click it, and leave your pointer where it is, the link gains focus, and you get both the :hover and :focus styles. If these happen to be identical then you won't notice that the link gained focus by clicking it. Half a second later you're rendering a new page.

I don't think Drupal core should try to suppress focus indicators for pointer users. Pointer users benefit from focus indicators too - they provide feedback that the thing that has just been clicked was the intended thing. That's useful for small targets which are near each other, like breadcrumbs, pagination, media player buttons, or the small dropdown from Drupal's Contextual Links.

...solution that made focus state indicators only appear when accessed via the keyboard

If there was a reliable way to tell them apart, like a well maintained third-party JS library, then we could provide stronger focus styles for keyboard users, and leave subtler ones in place for pointer users. I just don't like the idea of suppressing focus styles completely for pointer users.

:active styles are something we could consider, to provide strong feedback that the correct link was clicked, but this style only lasts during the mouse click itself. There's a strong demo at MDN :active.

Sorry @andrewmacpherson, I think I was unclear. I wasn't saying that we should suppress or remove focus states for mouse users - I meant that we could make a distinct set of focus indicators that are specifically for individuals who are keyboard users who may need a more prominent focus indicator without disrupting the ordinary focus indicator that is themed in for traditional users, like you're suggesting. My script does just that. :)

#34 - Yes, I like the sound of that explanation better! Is your script available to play with on Github, or somehwere? I think I've heard of some other similar scripts, but I can't remember the names, or whether they required jQuery, etc.

So the idea goes: Likely keyboard user detected... activate the enhanced focus styles!

Does it activate after any keyboard events, or do something clever like wait looking for tab/enter/spacebar/arrows?

I found this mention of focus outlines in the HTML 5.1 recommendation, in section 5.4.6 focus management APIs (emphasis mine):

Do not use this method to hide the focus ring if you find the focus ring unsightly. Instead, use a CSS rule to override the outline property, and provide a different way to show what element is focused. Be aware that if an alternative focusing style isn’t made available, the page will be significantly less usable for people who primarily navigate pages using a keyboard, or those with reduced vision who use focus outlines to help them navigate the page.

This says that focus styles do not solely benefit keyboard-only users, but it doesn't offer much explanation. What personas might this refer to?

Awesome! I haven't posted it on GitHub, but here's a preview. I'm using that to do some demo styles, but we can always fiddle with those once I put the patch up.

  /**
   * Accessibility - Make focus styles exclusive to keyboard by adding a
    * class to exclude focus styles from when focused via mouse
   */
  Drupal.behaviors.keyboardFocusStyles = {
    attach: function (context, settings) {
      $('body', context).on('mousedown', '*', function(e) {
        if (($(this).is(':focus') || $(this).is(e.target))) {
          $(this).closest('a').addClass('js-mouse-focus');
        }
      });
      $('body', context).on('focusout', '*', function(e) {
        $(this).closest('a').removeClass('js-mouse-focus');
      });
    }
  }

There's a lot of interesting discussion in the comments at Stop Messing with the Browser's Default Focus outline, including an old one I made then forgot about.

This comment from PatanjaliS is an interesting reminder not to treat mouse and keyboard users as distinct groups (emphasis mine):

Keyboard and mouse use are not necessarily mutually exclusive, and may be freely interchanged between, depending upon what input method was being used just before considering which to use next.
Having a visible focus, even if accessed by a mouse, indicates that the next field can be accessed by using the Tab key, which may make more sense to use if you had just typed in text, rather than the delay of going to the mouse just to change field when you are going to go back to using a keyboard anyway.

I agree with you about needing a focus indicator of some kind for both groups, but I do think that there's a certain amount of practicality to having distinct styles for each. Design and accessibility are often at odds with one another, since the very noticeable styling that is ideal for accessibility often isn't loved by designers, as the current trends are all about subtly. By isolating the focus states by mode of access we can give 'traditional' users an experience that won't start a war with those who prioritize design while still giving those who need something more attention-grabbing what they need.

Also, I get it about using the browser's default outline - it's usually not best practice to override browser styles. However, there are situations where there is a case for it to be made.

For instance, the blue outline isn't great on Bartik because the header region is already almost exactly the same color. There's not enough contrast there to benefit a low-vision user.

Here's what I've got so far. The styling may not be ideal since I'm not a designer, but it's in place to demonstrate potential functionality.

@helenasue That's cool, I'll give it a proper manual test soon.

We probably want to move forward by reviewing our current focus styles, and designing new ones where we find they are missing (or poor). I don't think a consensus was formed in the early comments (before #23 in June 2015).

Adding this JS library should probably wait until we've designed the keyboard-specific focus styles. (Maybe it will be a child issue.)

Meanwhile, a quick skim-read of the patch from #41 revealed this. Looks like an unintended change:

-  background: url(../../../../misc/feed.svg) no-repeat;
+  background: url(../../../../misc/feed.svg) no-repeat center center;

I like the general look of keyboard-a11y.js file. It seems lean enough, but someone with better javascript knowledge should review that. The behaviour is called keyboardFocusStyles but it works by excluding mouse actions. I wonder what we should do about other interactions like touch and stylus pointers? Maybe we should detect keyboard events instead?

keyboard-a11y.js should probably become a core system library (in core/misc) so any theme could use it. The focus CSS would live in Bartik and Seven, I think.

I've just noticed ten1seven/what-input which @mgifford mentioned back in #25. It's had releases this year and seems actively maintained. Worth a detailed comparison.

Thanks!

I agree, this shouldn't go in without further design first. I put it up to demonstrate how such a thing could theoretically work, but it's not ideally styled in its current state. I also agree that in retrospect I should have named it something more indicative of what it actually does rather than its ultimate purpose.

The 'center center' wasn't accidental, however - icons look better with a focus state applied when they are centered in their element. It makes the background or outline not off-center.

I'd be plenty happy for that to become a system library instead so that it can be used across the themes. I'm not sure about what-input, since I haven't used it or tested it, but I'm open to exploring that as an alternative. I only suggested my script because I've battle-tested it on client projects in the past successfully.

I am a bit worried, we might be making Bartik less pretty across the board with "one" focus style. Can we adapt and only provide focus styles where the "browser default" style might collide with existing styles (e.g. focus blue on blue background) albeit this is browser dependant.

a11y.js is another JS library which distinguishes whether the source of a focus event was keyboard or pointer. It provides ally.style.focusSource() method, and maintains a <html data-focus-source="key"> attribute for CSS use. Does not have a jQuery dependency :-)

Moving this to contrib since Bartik was removed from core in D10. But I am also marking it postponed because I am not sure whether it still needs to be actioned. Testing Bartik with D10, there is a clear focus style for each element.

Also tested Olivero just in case it still needed to be handled by core, but unsurprisingly it is well handled there too. So this issue may be obsolete.