WCAG 2.2 CR 3 updates

[alastc]

(PHL: added these) closes #3050 (?) and possibly closes #3086 (?)

Closes #3037
Closes #3050
Closes #3051

Preview focus appearance.
Preview target size.

(PHL: updated raw githack links - protip: make the raw githack links point to the PR branch, rather than individual commit versions, so the links here always remain in sync with any further changes to the PR)

---

Preview | Diff

[bruce-usab]

+1 for this PR. @alastc missing is the update to AAA Success Criterion 2.5.5 Target Size (Enhanced) inline exception (to match the inline exception of the new Target Size (Minimum) SC).

[patrickhlauke]

assume this PR supersedes #3089

[patrickhlauke]

need to work out relationship to #3097 as we now have variations around the same area all making slightly different updates

[patrickhlauke]

does this need a new definition somewhere for "bounding box"?

[patrickhlauke]

probably something very high-level like https://developer.mozilla.org/en-US/docs/Glossary/Bounding_box (rather than that definition of "minimum bounding box" that used to be used for focus appearance)

[alastc]

Well, seeing as focus-appearance doesn't use that definition any more, I think we can re-use it here. The latest push includes that change.

[patrickhlauke]

I do think the definition on https://developer.mozilla.org/en-US/docs/Glossary/Bounding_box is quite nice and concise. also, not quite sure what "For components which wrap onto multiple lines as part of a sentence or block of text (such as hypertext links), the bounding box is based on how the component would appear on a single line." part of the minimum bounding box definition actually means/shakes out to, so if we ARE going with that definition, this may need some clarification

[bruce-usab]

I agree that the Mozilla bounding box is definition seems sufficient. We have the wrinkle that our bounding box for hypertext is to based on the bounding box formed when linked text is unspooled to a single line.

[alastc]

need to work out relationship to #3097 as we now have variations around the same area all making slightly different updates

I'll take the text from this, and later apply the formatting from 3097.

[patrickhlauke]

i'm still unclear what that second part actually means in practice...how would I imagine a link on a single line? it's a bit cryptic

[patrickhlauke]

this also makes it confusing when considering targets that are fragmented on purpose somehow...would the "pretend it's all together" approach apply to them too?

[patrickhlauke]

ah, as you were, I see you answered this in the email

The second sentence about wrapping targets should not apply to target size because, by the definition of target, it is “a region” rather than multiple regions.

It should also not come up due to the inline exception.

[patrickhlauke]

however, are you re-applying this second sentence here in the PR? or am I getting confused?

[alastc]

It is applicable to focus-appearance, and yes, if the link were not wrapped, that's the size.
It is not applicable to target-size, both due to the inline exception, and because a target is defined as a region (not multiple regions).

[alastc]

I just want to get down the rational for the perimeter example, mostly based on an email from @dbjorge.

---

Whether you include corner pixels depends on whether we think that the 2px thickness of the perimeter should be drawn such that:

a. The thickness of the perimeter line is centered on the boundary of the control, ie, 1px of the line is drawn overtop the shape and 1px of the line is drawn outside the shape, or
b. both of the 2px is drawn outside of the shape

The definition is a bit ambiguous about this. It currently reads “continuous line forming the boundary of a shape not including shared pixels”. We have been interpreting that using “a”, but I could see someone interpreting the “not including shared pixels” part as implying “b”.

Using interpretation “a”, like we’d discussed last week:

• Rectangle case:
  • The inner pixel’s worth of thickness is 2w + 2h - 4 (ie, what the current example suggests) and the outer pixel is 2w + 2h + 4, for a total of 4w + 4h
  • Second equivalent way to calculate it: It is the area of a (w+2) by (h+2) rectangle minus the area of a (w-2) by (h-2) rectangle, ie, (w+2)(h+2) - (w-2)(h-2) = 4w + 4h
• Circle case:
  • It is the area of a (r+1) radius circle minus the area of a (r-1) radius circle, ie, 𝜋(r+1)^2 - 𝜋(r-1)^2 = 4𝜋r

Using interpretation “b”, like your diagram below:

• Rectangle case:
  • As you counted in your diagram, there are 16px of “extra” pixels to count, and counting pixels gets you to 4w + 4h + 16
  • Second equivalent way to calculate it: It is the area of a (w+4) by (h+4) rectangle minus the area of a w by h rectangle, ie, (w+4)(h+4) - wh = 4w + 4h + 16
• Circle case:
  • It is the area of a (r+2) radius circle minus the area of a r radius circle, ie, 𝜋(r+2)^2 - 𝜋r^2 = 4𝜋(r+1)

Really, this comes down to what we think the pass/fail boundary of Focus Appearance should be. Do we think that an author using a well-contrasting, 2px thick CSS border property (which gets drawn on this inside of the component) should pass the requirement? If so, we should actually be going with a third option “c” that draws the entire perimeter inside the shape and ends up arriving at 4w + 4h – 16 and 4𝜋(r-1), respectively.

---

My thought was: keep it simple and just go with 4 * W + 4 * H, and 4𝜋r.

Also, as this is to create an area, measuring the outside 1px of the component and doubling it is reasonable, the actual size of a 2px thick outline will be bigger by a few pixels.

[bruce-usab]

Where are we with definition for perimeter? I think it is (emphasis added):

continuous line forming the boundary of a shape not including shared pixels, or the minimum bounding box, whichever is shortest.

I am fairly certain we are much better off deleting not including shared pixels. I get that we are talking about a rendering of a line that has some thickness to it (in pixels). But the common understanding of the the term is that it is a zero-thickness line, so a measure of length and not an area. We are also, with this definition, making perimeter a synonym to bounding-box which is okay since the boundary of a bounding box also defined as having zero thickness.

The example hangs a lampshade on the problem:

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.

Please move the detail of subtracting off the corners elsewhere. It could be a note to the SC or to Understanding. It does not belong in a definition for perimeter. An alternative is for the note to go into detail for counting pixels making up the rendered perimeter, but in that case, the px thickness of the line must be mentioned.

[WilcoFiers]

This note is wrong. A 2px border around the perimeter isn't 2 * width + 2 * height. You're missing the corners in that. Instead its 2 * (width+2) + 2 * (height+2). And for a circle it's not 4𝜋 * radius. It's 2𝜋 * (radius+1) + 2𝜋 * (radius+2).

[awkawk]

Wilco, the example is 2h+2w-4, not 2h+2w. You are measuring the internal width and height in your calculation, which I guess we should be clear on which way is correct. I thought that we had settled on the original form (2h+2w-4).

For the circle, you are saying the same thing, except perhaps making it less clear since you do part of the math. The perimeter of a circle is 2𝜋r (or 𝜋d as I learned it) so if we want to clarify the computation for different border thicknesses we should use 2𝜋r*border thickness. And again, we need to clarify if the border is inside or outside the circle itself.

I think that we might need to just mention that authors and evaluators need to start with the basic formula and make adjustments if the border extends beyond the bounds of the shape.

[JAWS-test]

In my opinion, it makes no sense to count the actual pixels for a rectangle and therefore subtract the corner pixels, but for a circle take the theoretical pixels and subtract nothing. The actual pixels for a circle can deviate considerably from 4 x PI x radius, especially for small circles.

[alastc]

Hi Wilco,

See the comment above. Drawing the perimeter outside the component would lead to odd fails, by a few px.

Drawing it with 1px inside, 1px outside leads to the simplest calc as 2w + 2h - 4 and the outer of 2w + 2h + 4, giving total of 4w + 4h.

Drawing both pixels of the perimeter inside would be the most conservative, with the exact calc being 4w + 4h – 16.