[Target size]: UA controlled rule #2182
Conversation
Jym77
added
Rule
Jym77
requested review from
carlosapaduarte,
dd8,
tbostic32,
daniel-montalvo and
giacomo-petri
|
|
||
| Directly setting the `height` or `width` CSS properties makes an element not User-Agent controlled. Changing the `max-height` or `min-width` properties can make it not User-Agent controlled, if the added constraint impacts the [computed][computed values] `height` or `width` properties (i.e., if the `height` would be larger than `max-height` and is restricted by it; or if the `width` would be smaller than `min-width` and is changed by it). | ||
|
|
||
| [cascaded value]: https://www.w3.org/TR/css-cascade-5/#cascade-value 'CSS definition of computed value' |
There was a problem hiding this comment.
| [cascaded value]: https://www.w3.org/TR/css-cascade-5/#cascade-value 'CSS definition of computed value' | |
| [cascaded value]: https://www.w3.org/TR/css-cascade-5/#cascaded 'CSS definition of cascaded value' |
anchor seems not existing
| Directly setting the `height` or `width` CSS properties makes an element not User-Agent controlled. Changing the `max-height` or `min-width` properties can make it not User-Agent controlled, if the added constraint impacts the [computed][computed values] `height` or `width` properties (i.e., if the `height` would be larger than `max-height` and is restricted by it; or if the `width` would be smaller than `min-width` and is changed by it). | ||
|
|
||
| [cascaded value]: https://www.w3.org/TR/css-cascade-5/#cascade-value 'CSS definition of computed value' | ||
| [computed values]: https://www.w3.org/TR/css-cascade-3/#computed 'CSS definition of Computed Value' |
There was a problem hiding this comment.
| [computed values]: https://www.w3.org/TR/css-cascade-3/#computed 'CSS definition of Computed Value' | |
| [computed values]: https://www.w3.org/TR/css-cascade-5/#computed 'CSS definition of Computed Value' |
updated with css-cascade-5 new version
| [cascaded value]: https://www.w3.org/TR/css-cascade-5/#cascade-value 'CSS definition of computed value' | ||
| [computed values]: https://www.w3.org/TR/css-cascade-3/#computed 'CSS definition of Computed Value' | ||
| [implicit role]: #implicit-role 'Definition of Implicit Role' | ||
| [origin]: https://drafts.csswg.org/css-cascade-5/#cascading-origins 'CSS definition of Cascading Origin' |
There was a problem hiding this comment.
| [origin]: https://drafts.csswg.org/css-cascade-5/#cascading-origins 'CSS definition of Cascading Origin' | |
| [origin]: https://www.w3.org/TR/css-cascade-5/#cascading-origins 'CSS definition of Cascading Origin' |
updated with last candidate recommendation
| - the element is [focusable][]; and | ||
| - the element [computed value][] of the `pointer-events` CSS property is `auto`; and | ||
| - through scrolling, it is possible to have parts of the element's [border box][] which intersect the viewport and are not entirely covered by the [border boxes][] of elements with greater [computed][computed value] `z-index` and a [computed][computed value] `pointer-events` of `auto`. | ||
|
|
There was a problem hiding this comment.
Should we add a bullet point to clarify that the element must be visible (i.e., it is not set to display:none or visibility:hidden, it is not positioned out of the viewport such as left:-99999px, and its computed width and height are greater than 0)?
Without this clarification, it still makes sense theoretically, since the element can be targeted by a pointer event. However, if the element is not visible, this condition becomes practically useless as it cannot be targeted by a pointer device.
Or perhaps it is fine to keep it as is, but this statement should be defined within the applicability section for each rule.
| - Not all HTML elements that match this definition can actually be targeted by a pointer event. For example, when the actual clickable area does not cover the full [border box][] and is entirely covered by other elements, or when the element has an event handler that does nothing. Elements that match this definition but cannot actually be targeted by pointer events likely fail [Success Criterion 2.5.6 Concurrent Input Mechanisms][sc256]. | ||
|
|
||
| [border box]: https://www.w3.org/TR/css-box-3/#border-box 'CSS definition of Border Box' | ||
| [computed value]: https://www.w3.org/TR/css-cascade-3/#computed 'CSS definition of Computed Value' |
There was a problem hiding this comment.
| [computed value]: https://www.w3.org/TR/css-cascade-3/#computed 'CSS definition of Computed Value' | |
| [computed value]: https://www.w3.org/TR/css-cascade-5/#computed 'CSS definition of Computed Value' |
updated with last definition
| height: 50px; | ||
| width: 500px; |
There was a problem hiding this comment.
| height: 50px; | |
| width: 500px; | |
| min-height: 50px; | |
| min-width: 500px; | |
| color: transparent; |
together with the CSS edit below, it ensures that if users zoom text only, the button is still covered by the red bordered box
| <body> | ||
| <button onclick="alert('hello')">Say Hello</button> | ||
|
|
||
| <div class="cover bad highlight"></div> |
There was a problem hiding this comment.
| <div class="cover bad highlight"></div> | |
| <div class="cover bad highlight">Say Hello</div> |
| ## Assumptions | ||
|
|
||
| - This rule assumes that [focusable][] `widget` are effectively clickable. If a widget is [focusable][] without being clickable, it may fail this rule while [Success Criterion 2.5.5 Target Size (enhanced)][sc255] and [Success Criterion 2.5.8 Target Size (minimum)][sc258] are satisfied. | ||
|
|
There was a problem hiding this comment.
We already have secondary requirements, but should we clarify, once more, that "User Agent controlled components" are not required by WCAG, and the author can still customize them?
I’m concerned because the failing examples (especially the second one) currently meet 2.5.8, and I don’t want a distracted reader to think that custom controls are not allowed.
|
Failed examples need to also fail the composite rule so that implementation reports can be correctly generated for tools that do not report on every atomic rule. |
| <style> | ||
| input[type='radio'] { | ||
| width: 1em; | ||
| height: 1em; | ||
| } | ||
| </style> | ||
| <fieldset> | ||
| <legend>Pick a color (required)</legend> | ||
| <label><input type="radio" name="color" value="blue" />Blue</label> | ||
| <label><input type="radio" name="color" value="yellow" />Yellow</label> | ||
| </fieldset> |
There was a problem hiding this comment.
| <style> | |
| input[type='radio'] { | |
| width: 1em; | |
| height: 1em; | |
| } | |
| </style> | |
| <fieldset> | |
| <legend>Pick a color (required)</legend> | |
| <label><input type="radio" name="color" value="blue" />Blue</label> | |
| <label><input type="radio" name="color" value="yellow" />Yellow</label> | |
| </fieldset> | |
| <style> | |
| input[type='radio'] { | |
| width: 1em; | |
| height: 1em; | |
| } | |
| fieldset { | |
| line-height: 1em; | |
| } | |
| </style> | |
| <fieldset> | |
| <legend>Pick a color (required)</legend> | |
| <label><input type="radio" name="color" value="blue" />Blue</label><br/> | |
| <label><input type="radio" name="color" value="yellow" />Yellow</label> | |
| </fieldset> |
| width: 35px; | ||
| height: 35px; |
There was a problem hiding this comment.
| width: 35px; | |
| height: 35px; | |
| width: 23px; | |
| height: 23px; |
|
|
||
| - the element is a [semantic `widget`][semantic role]; and | ||
| - the element is [focusable][]; and | ||
| - the element [computed value][] of the `pointer-events` CSS property is `auto`; and |
There was a problem hiding this comment.
Do we need to consider 'stroke' and 'fill'? These are valid for SVG elements. See https://developer.mozilla.org/en-US/docs/Web/CSS/pointer-events
| - the element is a [semantic `widget`][semantic role]; and | ||
| - the element is [focusable][]; and |
There was a problem hiding this comment.
I'm not sure both of these need to be true. At least one I would say.
| - the element is a [semantic `widget`][semantic role]; and | |
| - the element is [focusable][]; and | |
| - the element is a [semantic `widget`][semantic role] or is [focusable][]; and |
| - the element is a [semantic `widget`][semantic role]; and | ||
| - the element is [focusable][]; and | ||
| - the element [computed value][] of the `pointer-events` CSS property is `auto`; and | ||
| - through scrolling, it is possible to have parts of the element's [border box][] which intersect the viewport and are not entirely covered by the [border boxes][] of elements with greater [computed][computed value] `z-index` and a [computed][computed value] `pointer-events` of `auto`. |
There was a problem hiding this comment.
This is tough to parse. How about:
| - through scrolling, it is possible to have parts of the element's [border box][] which intersect the viewport and are not entirely covered by the [border boxes][] of elements with greater [computed][computed value] `z-index` and a [computed][computed value] `pointer-events` of `auto`. | |
| - through scrolling, it is possible to have parts of the element's [border box][] appear within the viewport; and | |
| - while scrolled within the viewport the element is not obscured by another element with a [computed][computed value] `pointer-events` of `auto`. |
| This definition tries to capture which HTML elements can actually react to pointer events. It is not possible to have an exact definition of these for two main reasons: | ||
|
|
||
| - Sometimes, the element that handles the event is not the element that appear to react to it, but an ancestor (or descendant) capturing the event during propagation or bubbling. In the most extreme case, the `body` element of a page could be the only one with an event handler, acting differently depending on where the event actually occurred. In such a case, a button would be perceived by users as something that can be targeted by a pointer event, while technically it is the `body` element which is targeted. | ||
| - It is not possible to query the list of event listeners on a given elements. Some User Agents offer way to monitor events fired at a given element, but none offer a way to query for event listeners. Additionally, an event listener might ultimately do nothing and thus, for users, the corresponding element wouldn't look like it can be targeted by pointer events (since it effectively wouldn't react to them). |
There was a problem hiding this comment.
That's not quite true. Most browser devtools panels can show this. There just isn't a built in DOM method.
| title: User-Agent Controlled Component | ||
| key: user-agent-controlled-component |
There was a problem hiding this comment.
Feels unnecessarily verbose. Was there a reason we can't use UA control that I missed?
| title: User-Agent Controlled Component | |
| key: user-agent-controlled-component | |
| title: User-Agent Control | |
| key: user-agent-control |
| - the element has an [implicit role][] which is a [semantic `widget`][semantic role]; and | ||
| - the [computed values][] of the element's `height` and `width` CSS properties do not depend on content provided by the author; and | ||
| - the [computed values][] of the element's `height` and `width` CSS properties do not depend on any CSS property with a [cascaded value][] with "Author" [origin][]. |
There was a problem hiding this comment.
This feels off. For starts, font-size is a CSS property often set by the author that changes the width and height.
I'm also not sure whether this then includes things that feel like they shouldn't. An input[type=text] element can be adjusted by the size attribute. I don't think that then creates an author-origin CSS property.
Since #2167 is getting way too big, and according to CG call on April 11th, trying to extract the atomic rules to see if it can ease review.
This is an isolated rule for the larger "Target Size" rules. This rule alone makes little sense (as in, not checking anything valuable), please consider the bigger picture of #2167 while reviewing.
Closes issue(s):
Need for Call for Review:
This will require a 2 weeks Call for Review (new rule)
Pull Request Etiquette
When creating PR:
developbranch (left side).After creating PR:
Rule,DefinitionorChore.When merging a PR:
How to Review And Approve