Focus Appearance: Don't fail 1px outlines and rounded shapes

[WilcoFiers]

In the January 18th meeting, discussed using the border-box as the way to determine the size of components in HTML. The following note was to be added (PR pending):

Note: In HTML the size of a component is measured up to and including the CSS border.

I didn't notice this at the time, but going back through the understanding document today I realised that this now introduces new problems. In particular, the round button example from the understanding document may not meet the SC anymore:

Unusual shapes and gradients
If you have an unusual shape (not rectangular), some mathematics may be required if the focus indicator is on the edge of the size requirement. For example, if the focusable control is a circle with a diameter of 100px, the circumference would be 314 pixels. A 1px (or greater) outline would meet the size criterion.

If we're saying that in HTML, border-box needs to be used, that means the perimeter of that button is 100x100, and so the minimum focus area would be 400px, not 314px. This wouldn't just be true for circular buttons. This would be true for any control with rounded corners.

I'm not sure what to suggest as a solution here. One option could be to say it's border-box, excluding border-radius. The note as it was proposed sort of suggests it might be. That further complicates things though, and it then begs the question; if we're excluding border-radius, why not clip or overflow?

Even if we excluded border-radius, there are other ways to achieve that rounded / cut corner effect there the exception wouldn't be allowed. SVGs for example, or background images. In particular the CSS paint API is relevant there.

[bruce-usab]

Instead of making border-box might the way the way to determine the size of components in HTML, might it just be noted as one way? I agree that rounded corners and circles should not be excluded. Another approach is to work the match metrics from the other direction — for the example above, this could min height or width of 100px and min focus/target area of 314px.

[patrickhlauke]

my reading of "up to and including the CSS border" was a more broad "whatever the visual border/edge of the thing is" rather than the element's formal border-box/bounding box. but yes that should be clarified.

otherwise, if we're talking about the actual dimensions of the element itself, i could envisage controls that have a very large clickable area done with, say, padding, and inside them a much smaller "apparent" control, and those would likely fail if the actual clickable area/dimension/border-box had to be taken into account.

[patrickhlauke]

as in, imagine something roughly like this...

<button>
  <span>I'm a button</span>
</button>

button { width: 100vw; height: 100vh; display: flex; justify-content: center; align-items: center; background: transparent; border: none; }
button span { background: #eee; padding: 1em; border: 1px #000 solid; }

the button itself is as large as the viewport, but visually what user may perceive as the button is only small and centered. so in terms of focus appearance, i'd expect having a sufficient border just around the <span> would be enough, rather than referencing the actual size of the button element...

[alastc]

@patrickhlauke I went through a few of those connotations here: https://codepen.io/alastc/pen/eYGoKyP

I've added a border-radius example, and interestingly the box seems to be within the visible area:

Does border-radius add to the visual size of the component?

I have to close my computer now, but if anyone can work out if that passes the letter of the SC now, it might not be an issue?

[patrickhlauke]

@patrickhlauke I went through a few of those connotations here: https://codepen.io/alastc/pen/eYGoKyP

and what's the conclusion you came to? i.e., making my case an actual one: would https://codepen.io/patrickhlauke/pen/xxPdQOd pass or fail (if only what visually appears to be the button actually shows a focus outline)

[alastc]

With this note:

Note: In HTML the size of a component is measured up to and including the CSS border.

And the focus on 'component' rather than 'user interface component', the idea was that it's the keyboard interactive element, i.e. the button. So that example would fail due to the gargantuan area of the button.

The tricky bit about border-radius is if the outline chops off the area of the button then the reported size would be larger than the outline.

However, it looks (from a brief look) like adding a border-radius keeps the same size for the outline, because the non-rounded bits expand out of the area? I wasn't expecting that, so I'm not sure I'm interpreting that correctly.

Update: Just found the PR for this in #2188, and I added a version of your example to the codepen page of examples.

[patrickhlauke]

So that example would fail due to the gargantuan area of the button.

that sounds...less than ideal, as it really doesn't make sense from a logical "why wouldn't it be enough as it is?" point of view, particularly as it's impossible to explain to somebody why that example would fail while the exact same look and feel (but this time with the <button> in the centre, rather than the <span> would pass. i'd seriously push to reconsider this, rather than going for "easier to explain / more expedient to test"

ok, split out this other aspect into its own issue #2226

[guyhickling]

Note: In HTML the size of a component is measured up to and including the CSS border.

That note on the PR needs to be reworded, because, though it is somewhat vague, it isn't strictly true, as it reads. Whether the border is included in the size of a component is governed by the CSS box-sizing attribute, which has two values, border-box and content-box. Web content may use either of them. If you add CSS box-sizing="border-box" then, yes, the height and width include any border. And it is certainly the most popular value used.

But if you don't add that, the default value is "content-box", where an element's height and width includes only the content area, and the border is outside of that. In that case, if an element with height and width both 100px has a 1px border, then the overall size of the component is (100+2) x (100+2) i.e. 102 x 102. See https://developer.mozilla.org/en-US/docs/Web/CSS/box-sizing for more detail.

But in any case I don't see that border-box is relevant to this SC2.4.11. We just need to say "size of a component including its border" or similar. Perhaps what the note should say is "In this SC [2.4.11] the size of a component is measured up to and including the CSS border", not "In HTML"?

Also, just to clarify something else said above, adding a border-radius to round off a border's corners does not increase the size or area of the component. Its height and width stay the same. (But the corner bits are removed, so it actually becomes smaller in area.)

[alastc]

Whether the border is included in the size of a component is governed by the CSS box-sizing attribute

I don't think that's a problem here. We are saying that you'd measure the pixel size of a component as the area up to and including the border. Which model it is using will affect how large it is (if a width/height is set), but in either case you can measure the output.

The 'in HTML' was to differentiate from PDF etc.

[guyhickling]

Yes, that's right. I was just wanting to clarify that comment in the original post.

As regards the wider issue here, provided it is made clear exactly what is meant by the word "component" in the SC, that should resolve most if not all questions.

So I think some additions are need to the Understanding doc to cover various cases.

Most cases are easily resolvable if we treat "component" as referring to the actual interactive element. Looking through those Jan 18 meeting notes linked to above, it seems that meeting came to the same conclusion - "RESOLUTION: Carry on with the current approach, focused on 'component', tweaking the SC text to make clearer the basis for size."

[guyhickling]

The following includes cases where I think more clarity needs to be given in the Understanding doc and/or green notes to make clear exactly what is meant by the word "component" in 2.4.11. So testers know exactly what to pass and what to fail. @alastc's list has many examples, so this comment is going to be a long one to cover them - apologies for that in advance.

HTML elements:

If we are using an HTML button or link or other interactive HTML element, then that element is the "component". And browsers, by default, agree with that by placing the focus outline round the outside of the perimeter of that component, including any border it may have, regardless of what visual effects are displayed inside it. I think some of the examples given above may be confusing visual effects with the interactive component.

If the outline is outside the component, and assuming it is at least 1px thick outline, then it will ipso facto be larger than the SC's "area of a 1 CSS pixel thick perimeter of the unfocused component" inside it.

Rounded corners:

In rounded corners using border-radius, the corner bits are no longer part of the component, by any reasonable definition of the component. And that's the way browsers think too, because they don't allow mouse clicking on those excluded corners, and their outline is usually rounded so it matches visually with that underlying interactivity (I checked that in Chrome and Firefox). So I don't see a problem with rounded corners.

Even if a browser, or a developer, were to create a rectangular focus outline round an element with rounded corners, so long as it is outside the component and it's border, then mathematically it has to be longer than the perimeter and/or border of the component inside it. Therefore so long as the outline is 1px thick then it will pass 2.4.11.

(True, there are other ways of doing rounded corners, such as the very old-fashioned way using images for the corners, but no one does that any more. Any old website still with them will almost certainly need a complete accessibility overhaul anyway!)

Circular buttons:

Regarding the original query, the "perimeter" or boundary of a round button is a circle, not the theoretical square box containing the circle. Border-box doesn't come into it; a circle perimeter is 2piR, and the WCAG definition of perimeter already includes that. So I think 2.4.11 is worded correctly in this particular.

However, to avoid future challenges, I do suggest that the Understanding document needs to cover the fact that circles, and rounded corners and suchlike, aren't actually circles on a PC screen, they are made up of rectangular pixels. But we are creating a new SC so we can decide what is needed.

The Understanding currently says only "For example, if the focusable control is a circle with a diameter of 100px, the circumference would be 314 pixels. A 1px (or greater) outline would meet the size criterion." That would be open to challenge and argument, so it needs to be clearer. We should add another paragraph in the Understanding, something along the lines of:

"We recognise that, on a PC screen, circles and rounded corners aren't actually round, they are made up of rectangular pixels so are very jagged in shape, and may be anti-aliased as well. But browsers accept an outline thickness specified in px units, even for rounded shapes, and they display that in an acceptable way. So the minimum of 1px for the focus outline is still the minimum thickness to specify in CSS for these shapes.

Shadows:

If the component has a CSS shadow effect, I don't think the shadow should be considered as part of the component, it's just visual styling. The only requirement should be that the focus outline has sufficient contrast where it crosses the shadow (or else temporarily remove the shadow on focus as done in Alastair's Example 2).

If shadow is to be considered part of the component, then that will force developers to change the default size of the outline to make it big enough - one more thing for them to learn and remember for accessibility. and they have enough already!

But whether shadow is considered part of the component or not, this case should be specifically mentioned in the Understanding doc (or maybe in a green note under the SC), to say whether it is included in the "component" or not, so that it is clear to all. Currently the Understanding only mentions focus outlines that are shadows, not the case where the component has a shadow.

Non-HTML components:

Finally, there is the extremely common case of custom components, created out of a < div > element with a click event on it. Developers and JavaScript frameworks and libraries all do this. Here, I think the "component" can reasonably be considered to be that div that has the click event, regardless of any other ornamentation that may make it look bigger or smaller than it really is. We in any case tell them to put an ARIA role on that div, and tabindex and so on. So it should also be the element to have the focus outline.

But once again, this case needs to be described in the Understanding document so there is no doubt about it because it is so common.

Conclusion:

I am sure someone can come up with some weird shape or some outlandish design that will not fit easily with any definition of the word component. Maybe we can't hope to cover everything, so I think we need to be pragmatic about it. If the SC can cover 90% of common cases then we will have improved accessibility for people with disabilities. So long as the Understanding doc gives enough guidance for all the likely cases, I think that should suffice - the alternative is to end up with no SC at all, which helps no one.

[alastc]

Thanks for that @guyhickling, we'll need to do a pass on the understanding doc once the SC text is agreed (otherwise it'll be needed again!).

[alastc]

The latest text doesn't fail a 1px outline around a rounded shape, so this issue has been overtaken by changes.