Repository navigation
WCAG 2.2 CR 3 updates #3123
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -2,6 +2,6 @@ | |
| <dd class="new"> | ||
| <p class="change">New</p> | ||
| <p>continuous line forming the boundary of a shape not including shared pixels, or the <a>minimum bounding box</a>, whichever is shortest.</p> | ||
| <aside class="example"><p>The perimeter calculation for a 2 CSS pixel perimeter around a rectangle is 4<em>h</em>+4<em>w</em>, where <em>h</em> is the height and <em>w</em> is the width. For a 2 CSS pixel perimeter around a circle it is 4𝜋<em>r</em>.</p></aside> | ||
|
Contributor
There was a problem hiding this comment. 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).
Member
There was a problem hiding this comment. 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. There was a problem hiding this comment. 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.
Contributor
Author
There was a problem hiding this comment. 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. |
||
| </dd> | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -23,13 +23,13 @@ <h4>Target Size (Minimum)</h4> | |
| <p class="change">New</p> | ||
|
|
||
| <p>The size of the <a>target</a> for <a>pointer inputs</a> is at least 24 by 24 <a>CSS pixels</a>, except where:</p> | ||
| <ul> | ||
| <li><strong>Spacing:</strong> Undersized targets (those less than 24 by 24 CSS pixels) are positioned so that if a 24 CSS pixel diameter circle is centered on the <a>bounding box</a> of each, the circles do not intersect another target or the circle for another undersized target;</li> | ||
|
Member
There was a problem hiding this comment. does this need a new definition somewhere for "bounding box"?
Member
There was a problem hiding this comment. 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)
Contributor
Author
There was a problem hiding this comment. 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.
Member
There was a problem hiding this comment. 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
Contributor
There was a problem hiding this comment. 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. |
||
| <li><strong>Equivalent:</strong> The function can be achieved through a different control on the same page that meets this criterion.</li> | ||
| <li><strong>Inline:</strong> The target is in a sentence or its size is otherwise constrained by the line-height of non-target text;</li> | ||
| <li><strong>User agent control:</strong> The size of the target is determined by the user agent and is not modified by the author;</li> | ||
| <li><strong>Essential:</strong> A particular presentation of the target is <a>essential</a> or is legally required for the information being conveyed.</li> | ||
| </ul> | ||
| <p class="note">Targets that allow for values to be selected spatially based on position within the target are considered one target for the purpose of the success criterion. Examples include sliders with granular values, color pickers displaying a gradient of colors, or editable areas where you position the cursor.</p> | ||
| <p class="note">For inline targets the line-height should be interpreted as perpendicular to the flow of text. For example, in a language displayed top to bottom, the line-height would be horizontal.</p> | ||
| <dl><dt class="new"><dfn data-lt="target offsets">target offset</dfn></dt> | ||
|
alastc marked this conversation as resolved.
|
||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.