Minimum focus indicator definitions for 2.4.11/2.4.12 are ambiguous; example calculations do not account for corners

[36degrees]

Success Criterion 2.4.11 says:

The focus indication area is greater than or equal to a 1 CSS pixel border of the focused control

It's unclear whether this refers to:

• a border along the existing edge of the control, ‘overlapping’ the outermost pixels of the control or;
• a border around the outside of the control.

(Effectively, it depends whether you’re thinking about borders using the ‘border-box’ or ‘content-box’ box-sizing model)

In Understanding Success Criterion 2.4.11: Focus Appearance (Minimum), the guidance then says:

The minimum size of the focus indicator must be at least the area taken by a 1 CSS pixel border around the element.

This seems to suggest that the intent is for the minimum focus indication area to be equivalent to a border around the outside of the control, but it's still not 100% clear.

The example calculations do not help either, because they fail to take corners into account and would be incorrect for either case.

For example, if a control is a rectangle of 90px wide and 30px tall, the size of the outer border is 90 + 90 + 30 + 30 = 240 CSS pixels.

Every ‘corner pixel’ is being counted twice.

The area of a 1px border would in fact be either +/- 4px depending on whether the requirement is for a border along the existing edge of, or around the outside of the control.

For example, applying the same calculation for a 10px square you’d end up with 10 + 10 + 10 + 10 = 40 CSS pixels, but it’d actually be either 36 or 44px:

Similarly, to meet the 2px requirement for 2.4.12, a border around a 10px square would not be 20 + 20 + 20 + 20 = 80 but instead 80px +/- 16px:

Please can you clarify whether SC 2.4.11 and 2.4.12 refer to a border along the existing edge of the control, or a border around the outside of the control.

Defining it as a border along the existing edge would allow for 1px border of either type to be sufficient, but it’s unclear how this would interact with the ‘or has a thickness of at least 2 CSS pixels’ clause in the ‘adjacent contrast’ requirement – presumably the intent is that the control should visibly ‘grow’ by 2px whereas a low contrast 2px border along the existing edge of the control would probably not be perceivable?

Defining it as a border along the outside of the control avoids this, but would mean that a 1px border along the existing edge that otherwise met all contrast requirements would not be sufficient as it’d cover an area 8 pixels too small.

Once the ambiguity has been resolved, the example calculations would need to be updated.

[alastc]

I'd like to keep it as simple as possible, rounding off a few pixels isn't going to make a significant difference.

How about defining it as 'along the edge', and saying that we are not too concerned about small corners. E.g. using a border radius (more anti-aliasing) is not an issue.

[36degrees]

I'd like to keep it as simple as possible, rounding off a few pixels isn't going to make a significant difference.

I fully support keeping it simple as possible, but I also think it's important that the example calculations are correct – otherwise the apparent contradiction between what's written in the success criteria and the example calculations is going to cause confusion.

The 4 pixel difference in the calculations is significant if the focus state is a 1px border along the component edge, because the actual area of that border (if you actually count the pixels) is always going to be 4px short of the 'minimum focus indication area' value given by the calculations in the example.

How about defining it as 'along the edge', and saying that we are not too concerned about small corners. E.g. using a border radius (more anti-aliasing) is not an issue.

👍

However, I do just want to clarify, the original issue applies regardless of whether a border radius is used or not – even without a radius, the calculations do not account for the corners.

Finally, just picking up on one of my own comments from the initial post:

Defining it as a border along the existing edge would allow for 1px border of either type to be sufficient, but it’s unclear how this would interact with the ‘or has a thickness of at least 2 CSS pixels’ clause in the ‘adjacent contrast’ requirement – presumably the intent is that the control should visibly ‘grow’ by 2px whereas a low contrast 2px border along the existing edge of the control would probably not be perceivable?

Having worked through some more examples, I think this would be covered by the 'change of contrast' requirement, as if the focus used an 'inset' border, the pixels that make up the border would have to have 3:1 contrast against the same pixels in the unfocused control.

[awkawk]

I agree that we should clarify whether the requirement is to have base the area calculation on a border that is fully contained within the original dimensions of the control or if the expectation is that it is fully outside the original dimensions.

I believe that it is the former, based on the discussion.

I don't think that we need to clarify how to calculate the area of a 1px border - if people do it by multiplying width by height for a rectangular area they will overshoot the minimum. We can clarify this in the understanding document.

[36degrees]

if people do it by multiplying width by height for a rectangular area they will overshoot the minimum. We can clarify this in the understanding document.

I think this is more likely to cause issues where the focus state is being 'audited'. I think (although it is still unclear) that a focused control with a 1px border along the existing edge of the control should (?) pass. However, if someone auditing that control uses the calculations provided in the understanding documentation then they are going to find it 4 pixels short. This ambiguity is just going to cause confusion.

I agree that it's important for the calculations to be simple, but surely not at the expense of correctness – the calculations should be as simple as they can be within the constraints of being correct and unambiguous. If we can agree that that should be the goal then In my opinion, failing to take into account the corners in the calculations violates that.

I don't think that we need to clarify how to calculate the area of a 1px border -

I think the calculations could be very useful, but if they cannot be updated to be correct then they should just be removed because at the minute they just introduce additional ambiguity rather than clarity.

However as in my original comment I do think it is important that it's clear whether '1 CSS pixel border of the focused control' refers to:

• a border along the existing edge of the control, ‘overlapping’ the outermost pixels of the control or;
• a border around the outside of the control.

[alastc]

Hi @36degrees,

A recent update includes a definition for the perimeter to provide the calculation:

the continuous line forming the boundary of a shape. The perimeter calculation for a rectangle is 2 h +2 w , where h is the height and w is the width. The perimeter of a circle is 2 * Pi r.

That is outside the SC text, but linked to and normative.

It isn't 100% accurate but does provide a consistent calculation. Does that resolve your issue?

[36degrees]

Great to see the perimeter defined – I think it does resolve the first point (whether a 'border' is along the existing edge or around the outside) – but I still think the calculation is problematic.

The area of the focus indicator is at least as large as as the area of a 1 CSS pixel thick perimeter of the focused control

I'd interpret this as a 1px border around the element being sufficient to meet the criteria.

If you then use that perimeter calculation 2 h +2 w on a 10px square you'll end up with a calculated 'requirement' of 40px. However, referring back to the example in my first post, if you were to actually count the pixels on a 1px border of that 10px x 10px square you'll find you only have 36 pixels, because of the corners.

The SC says (pretty unambiguously) that a 1px border is sufficient, but the calculation says it isn't (you're 4 pixels short).

I think if a perimeter calculation is provided then it needs to work for the simplest example given by the SC.

[alastc]

(Tagging @mbgower as author of the perimeter definition).

So would it be better to make it 2h + 2w - 4px, or define it as the outline around the component?

I'm really hoping to keep this as simple as possible.

[36degrees]

I personally would interpret 'an outline around the component' to mean that a border along the 'existing' edge of the component would not be sufficient to meet the SC.

Unless that's the intention, I think 2h + 2w - 4px might be the simplest 'correct' calculation that allows a 1px border along the existing edge to meet the SC.

[mbgower]

Hmm, I'm thinking of this abstractly and not as implemented using a technology, so bear with me...
I have a button measuring 10x20 px, so my perimeter and minimum area is 60, right?
If I'm am going to add a 1 px border, wouldn't that mean my lines would measure 12, 22, 12, 22? If I only count the 4 corner pixels once, I'd get, 10,22,10,22=64.

It seems to me that adding a 1-pxl border would exceed the minimum? Apologies if I'm doing something really daffy with the calculation. I'm sure @alastc will correct me.

[alastc]

I have a button measuring 10x20 px, so my perimeter and minimum area is 60, right?

If you count the pixels, it would be 10 + 10 + 20 + 20 - 4 = 56.

If you add a line around/outside the component (outline in CSS terms), that line would be 64.

(I keep referencing the diagrams at the top for this mental process, really helps!)

So a border would not meet the minimum if it is defined as 2h + 2w, but an outline would.

Also worth noting that any internal outline like this one must be greater than a 1px line otherwise it will be a bit short:

[alastc]

Hi everyone, we agreed to update the perimeter definition to:

the continuous line forming the boundary of a shape, not including shared pixels. For example, the perimeter calculation for a rectangle is 2h+2w -4, where h is the height and w is the width and the corners are not counted twice. The perimeter of a circle is 2𝜋r.