Dotted outlines and focus indicators in SC1.4.12

[guyhickling]

Dotted lines
This SC will work well for borders and outlines that are solid lines. But too many designers seem to want to make their content as faint as possible, and if they choose to use dotted lines instead of solid ones they will be able to completely circumvent this SC as it stands.

A dotted line has vastly reduced visibility compared to a solid line in the same colour - not surprisingly since there is less than half the "ink" on the page. There isn't much point in having an SC specifying 4.5 or 3 to 1 contrast if designers and developers can simply sidestep it!

So I strongly recommend the SC be improved to stop this loophole.

Focus indicators
Secondly, I also consider focus indicators should be treated as a special case in the proposed SC, because they move around and are therefore harder to spot. Dotted lines are already the method of choice for focus indicators for designers that don't want to "spoil" their design. This causes massive problems for keyboard-only users, many of whom really struggle to see where focus currently is if they have anything less that 20:20 vision. And, of course, if the developer doesn't provide a focus indicator most browsers default to dotted.

Focus can jump large distances across or down the page as the keyboard user navigates, making it extremely difficult to find them again among a lot of other content. Users with poor vision can make out a field outline by staring at it, however faint it may, but they can't do that with an indicator that has just moved somewhere else. They have to find it again first! Focus indicators need to be more highly visible than other field components.

More contrast isn't the answer here - 3 and 4.5 are already good contrast. The answer for the focus indicator is to require a thicker outline - either a 2px or 3px minimum thickness. Designers and developers can be reminded that highly visible focus outlines do not impact on their page design since they are only seen on focus. That could be mentioned in the Understanding document.

To stop these loopholes
So I suggest some additional words and one extra exception be added into SC1.4.12 to make it read as follows:

Essential visual identifiers of user interface components have a contrast ratio of at least 4.5:1 against the immediate surrounding color(s), lines are solid not dotted or dashed, and authors provide solid lines for focus indicators of at least 2px in thickness, except for the following situations:

[then the existing exceptions, plus the following additional one:]

A dotted or dashed line can be used if at least 3px in thickness.

The "authors provide" bit is to require developers to provide their own focus indicator, because it is so critical to keyboard users, rather than relying on the browser defaults. This will address a problem for keyboard users who for too long have been largely neglected in this matter.

[goodwitch]

@guyhickling great suggestions. I will bring these suggestions up at the upcoming TPAC meetings. Perhaps we can have two solutions. A simple solution in WCAG 2.1 that moves us forward (since there are currently no contrast requirements for focus indicators at this point) and a future solution (maybe in Silver) where we have a feature that lets each person tune the Visual Focus Indicator to their own needs. Using the "oreo" method...and personalization, I can envision a personalized option (in Silver) where a user can easily pick their color and line thickness for focus indicators.

Even if all we get is 3 to 1 color contrast requirement on focus indicators (solid lines or dotted lines) it will be a big step in the right direction.

[patrickhlauke]

But too many designers seem to want to make their content as faint as possible, and if they choose to use dotted lines instead of solid ones they will be able to completely circumvent this SC as it stands.

Note that it's not always these dastardly evil designers' fault or active choice...it comes down to the fact that many browsers (IE, Firefox, ...) use dotted outlines by default.

[guyhickling]

Thank you for commenting, Patrick. That is true of course, and for that reason I suggested the wording:

and authors provide solid lines for focus indicators

so that developers are required to actively supply a focus indicator instead of just leaving it to whatever defaults browsers provide. Not a big task, just a few lines of CSS. Naturally they would have to provide indicators that comply with whatever this SC ultimately ends up recommending for focus indicators, which I hope will be, at the very least, a solid line of the recommended contrast.

I do think that keyboard-only users have been left for far too long at the mercy of whatever defaults the browsers offer, and with this SC we have a chance to make their online life easier.

[steverep]

... and authors provide solid lines for focus indicators ...

I certainly understand the impetus here, but I see a number of problems with trying to dictate style like this. First, border lines are far from the only way to indicate focus, and forcing one specific way would not only never fly with authors as being much too restrictive, but also have the unintended consequence of sending a message it's the "best" way when we have no data to support it. I could arguably provide much clearer focus indication by simply inverting the fill and text colors.

One reason I'd argue we have the user agent control exception is because we don't want every single page taking focus indication upon themselves. Lack of consistency for low vision would be a terrible unintended consequence. Yes, the browsers are ignoring everyone but those with perfect vision, but they need to be the ones to fix it.

[guyhickling]

border lines are far from the only way to indicate focus

You are absolutely right, of course, and I didn't take enough care over the wording there. The main intent of those words was to stop developers opting out and leaving it to whatever weak defaults browsers choose to give. I offer an improved wording below to avoid any restriction on the type of indicator used.

Regarding:

we don't want every single page taking focus indication upon themselves

That is already happening. Many sites already design their own focus indicators (I haven't actually done a count on this, but probably half the websites I audit do their own). Some because they take keyboard accessibility seriously and realise the lack of visibility of the browser defaults, some because they just want to do it differently (and some of the latter end up with focus indicators even less visible than the dotted lines of the browsers!

An increasingly popular indicator used by some sites is to have a solid, bright orange outline on focus, usually of 2 or 3px thickness. And some use inverted fore and background colours which, as you rightly say, is probably more distinctive and visible than an outline.

I certainly don't think we should wait for the browser manufacturers. The current state has existed for years, with little progress because it just is not top of their agenda. This can, and should, be tackled very easily at the development end. It is a tiny addition to their work to specify focus indicators, a few lines of CSS only. They design everything they want fully sighted people to see, in meticulous detail. Now this SC is asking them to pay just a small amount of attention to people with imperfect eyesight, including an ever increasing number of elderly people who use the internet as much as any of us. But the SC will only achieve that if it stops the get-out of using dotted lines.

Improved wording:

To improve the wording of the original suggestion then, instead of "...and authors provide solid lines for focus indicators..." how about:

...and any part of a an input field or control or focus indicator that is a line is a solid line...

(there is still the suggested exception that dotted lines are ok if they are thick enough, which I put at 3px or more. They wouldn't be banned so long as they are sufficiently visible.)

These suggestions are not intended to restrict designers and developers needlessly, merely to ensure this very important (to keyboard users) part of their work is accessible.

[goodwitch]

@guyhickling @patrickhlauke So, I'm that girl who truly believes that the browsers will improve the default focus indicators...and I've already started those conversations. I don't want to lay the burden of bad default focus indicators at the feet of innocent developers and designers. The world has very limited resources...I want us to solve this problem as efficiently as possible.

If either of you want to volunteer to draft sufficient techniques...that inspire people to use solid lines, that would be great. I'll be candid, I think just getting this into WCAG 2.1 to require a measurable color contrast is a big leap forward. If we find that it is not enough...we can always go further in a future dot release...or in silver.

[guyhickling]

And I'm the grumpy old so and so who believes that developers shouldn't be lazy and expect the browsers to do all their work for them! (and hey, I was a developer before coming into this work, so I'm not expecting anyone to do anything I haven't done myself many times!)

But let's just be clear about how massive a task this is for them to do. Here is the CSS they need to add to put a focus outline around all links and buttons on their website:

button:focus,
a:focus {
outline : 2px solid blue;
}

And they might want a similar line or two if they have any custom-built interactive components. They can go different routes, such as reversing the fore and background colours on links. But I'm suggesting, if it's a line, then it should be solid for good visibility as well as contrasting.

So that's it. It's as easy as that! Most websites already create their own indicators for hover by mouse users, designers often specifically not wanting to delegate what they see as an important design decision to the browsers. The reason they haven't done it for focus as well is they haven't realised it's problem for anyone and no one has told them. That's what the WCAG should do.

An SC relying only on contrast to give links and input fields good visibility will be circumvented by all those designers who like stuff to be as faint and hard to see as possible, and they will be able to use dotted lines to do it. There's a whole lot of keyboard users out there who have already waited through two WCAG generations to be noticed. We shouldn't make them wait again!

[goodwitch]

@guyhickling I totally get that it is a best practice for developers and designers to proactively fix this. But not all websites have active developers and designers. And there is limited time/energy in this world. So, I feel it is very important that we use all time and resources wisely.

Fixing this at the browser level will have a huge immediate positive effect. And it is very frustrating to think we wouldn't try to get this fixed at the browser level...why let the default be inaccessible.

And while this is a "simple technical fix" for a developer...developers don't usually pick colors...and colors get into design and branding....and you know how much fun it is to get branding colors changed. Fixing this at the browser default will bypass the mire of political branding color issues (for all sites use the browser defaults).

[johnfoliot]

+1 to Glenda and Steve. Being old and grumpy myself, and having fought this battle many times before over the past two decades, I would still be extremely opposed to any SC that is so prescriptive as to remove designer choice from the equation. I fully agree that the default visual indicator in the browsers could stand for some serious re-thinking and upgrading (note to Project Silver folk), but I would resist any Success Criteria wording that demands solid lines be used as the only way of a visual indication, or even that if the design calls for a 'border' as focus indication that it MUST be a solid line. WCAG Success Criteria should state the functional requirement (here essentially, ensure visible tab focus is visible to low-vision users at all times), but avoid mandating a specific technique. The fastest route to pushback and outright rejection is to be overly constraining on designers and developers, and this kind of explicit demand is what also leads to the (untrue, but still widely held) view that accessibility makes sites boring or ugly. JF

…

On Thu, Oct 12, 2017 at 11:17 AM, Glenda Sims ***@***.***> wrote: @guyhickling <https://github.com/guyhickling> I totally get that it is a best practice for developers and designers to proactively fix this. But not all websites have active developers and designers. And there is limited time/energy in this world. So, I feel it is very important that we use all time and resources wisely. Fixing this at the browser level will have a huge immediate positive effect. And it is very frustrating to think we wouldn't try to get this fixed at the browser level...why let the default be inaccessible. And while this is a "simple technical fix" for a developer...developers don't usually pick colors...and colors get into design and branding....and you know how much fun it is to get branding colors changed. Fixing this at the browser default will bypass the mire of political branding color issues (for all sites use the browser defaults). — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#424 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABK-c5sgmEMRWzDRx_D5tVJi3DOIVowmks5srjuHgaJpZM4PxeGA> .

-- John Foliot Principal Accessibility Strategist Deque Systems Inc. [email protected] Advancing the mission of digital accessibility and inclusion

[awkawk]

We appreciate the concern, this is something that ties back to the user-agent behaviour which is a target for improvement in the 'Silver' version of the guidelines which can provide guidance for user-agents as well as authors. The SC for 2.1 can have a sufficient technique which uses the best-practice of solid lines.