w3c/wbs-design
or
by mail to sysreq
.
The results of this questionnaire are available to anybody.
This questionnaire was open from 2021-11-10 to 2021-12-07.
13 answers have been received.
Jump to results for question:
The ACT Task Force would like to publish the following rule:
Form field has non-empty accessible name
Do you agree with the proposal from the ACT Task Force to publish this rule?
Choice | All responders |
---|---|
Results | |
I approve of the rule being published | 8 |
I approve of the rule being published with adjustments (please comment) | 2 |
I do not approve because (please comment) | 1 |
(2 responses didn't contain an answer to this question)
Responder | Form field has non-empty accessible name | Comments |
---|---|---|
John Foliot | I approve of the rule being published | |
Laura Carlson | I approve of the rule being published | |
Gregg Vanderheiden | ||
Rachael Bradley Montgomery | I approve of the rule being published | |
Oliver Keim | I approve of the rule being published with adjustments (please comment) | The section "Inapplicable" contains some temporarily hidden elements which validate OK, although they fail when the elements reach a visible state. Many web pages dynamically show controls depending on user interaction. For such cases the web page would validate OK, but fail at the time the "inapplicable" element gets a visible state. |
Gundula Niemann | I approve of the rule being published with adjustments (please comment) | no backdoors rules should be as simple as possible to avoid human errors and blown-up automated tests. So, the result on checking one attribute should not rely on the value for another attribute, like being disabled or hidden. This might change any time. |
Wilco Fiers | I approve of the rule being published | @Mike: 1. Test cases aren't exhaustive. If you feel a test case showing the title attribute is important, we can certainly add one. 2. I'm not sure why two controls having the same name would be a failure. Even if it was, that seems like it should be its own rule. @Oliver / @ Gundula; I don't think those examples fail WCAG. Even if you're right that when the state changes they do (which we don't know), failing them in a rule, when they don't fail WCAG itself doesn't seem appropriate. It isn't allowed by the ACT rules format either. |
Jeanne F Spellman | I approve of the rule being published | |
Jaunita George | I approve of the rule being published | |
Bruce Bailey | I approve of the rule being published | |
Michael Gower | I do not approve because (please comment) | 1) There is a note about the use of title with some ATs in the preamble, but there is neither a pass or fail example using title, despite it being an acceptable part of the computation. I'd like to understand this. 2) maybe there should be a fail scenario (where 2 items have the same name). If there was no aria labelling (or describing) happening, then it would be an inapplicable example. I'm scanning this quickly, so apologize if I've missed a nuance. |
Andrew Kirkpatrick | I approve of the rule being published | |
Jonathan Avila |
autocomplete
attribute has valid value
Do you agree with the proposal from the ACT Task Force to publish this rule?
Choice | All responders |
---|---|
Results | |
I approve of the rule being published | 8 |
I approve of the rule being published with adjustments (please comment) | 3 |
I do not approve because (please comment) | 1 |
(1 response didn't contain an answer to this question)
Responder | Attribute has valid value | Comments |
---|---|---|
John Foliot | I approve of the rule being published | |
Laura Carlson | I approve of the rule being published | |
Gregg Vanderheiden | ||
Rachael Bradley Montgomery | I approve of the rule being published with adjustments (please comment) | Under applicability, stating that this rule does not apply when a automcomplete tag is needed but no attribute is present would make this easier to understand on first reading. That said, I will not object to the current langauge. |
Oliver Keim | I approve of the rule being published with adjustments (please comment) | Disabled elements are treated as inapplicable, however, if the element becomes visible these samples would fail. |
Gundula Niemann | I do not approve because (please comment) | in fact, no answer (technical issue with the questionnaire) |
Wilco Fiers | I approve of the rule being published | @Rachael: See Q2 response. |
Jeanne F Spellman | I approve of the rule being published | |
Jaunita George | I approve of the rule being published | |
Bruce Bailey | I approve of the rule being published | |
Michael Gower | I approve of the rule being published | |
Andrew Kirkpatrick | I approve of the rule being published | |
Jonathan Avila | I approve of the rule being published with adjustments (please comment) | Whether the value is accurate or not is not a hard fail of WCAG as if the field is not listed then it doesn't matter if it has invalid autocomplete. |
The ACT Task Force would like to publish the following rule:
Element marked as decorative is not exposed
Do you agree with the proposal from the ACT Task Force to publish this rule?
Choice | All responders |
---|---|
Results | |
I approve of the rule being published | 6 |
I approve of the rule being published with adjustments (please comment) | 3 |
I do not approve because (please comment) |
(4 responses didn't contain an answer to this question)
Responder | Element marked as decorative is not exposed | Comments |
---|---|---|
John Foliot | I approve of the rule being published | |
Laura Carlson | I approve of the rule being published | |
Gregg Vanderheiden | ||
Rachael Bradley Montgomery | ||
Oliver Keim | I approve of the rule being published with adjustments (please comment) | samples with role=presentation are missing. |
Gundula Niemann | ||
Wilco Fiers | I approve of the rule being published | @mike, Agreed, passed 4 might be better as the first example. Will put in a fix Regarding alt=""; An image with a completely empty alt is given the implicit role of presentation, see https://www.w3.org/TR/html-aria/#el-img-empty-alt @Oliver; These test cases aren't exhaustive. Still, wouldn't be difficult to swap some of the none's. I'll put in a fix. |
Jeanne F Spellman | I approve of the rule being published | |
Jaunita George | I approve of the rule being published | |
Bruce Bailey | I approve of the rule being published | |
Michael Gower | I approve of the rule being published with adjustments (please comment) | Shouldn't pass example 4 be the first example (image with an empty alt). It is the most common occurrence. If the rules are not constructed to be most common first, ignore my comment. As someone weak in this space, I wanted a bit more information on how an image with alt="" is treated in the tree. I couldn't see much . |
Andrew Kirkpatrick | I approve of the rule being published with adjustments (please comment) | Not sure if possible to fail this, maybe I'm misunderstanding |
Jonathan Avila |
The ACT Task Force would like to publish the following rule:
Letter spacing in style attributes is not !important
Do you agree with the proposal from the ACT Task Force to publish this rule?
Choice | All responders |
---|---|
Results | |
I approve of the rule being published | 6 |
I approve of the rule being published with adjustments (please comment) | |
I do not approve because (please comment) |
(7 responses didn't contain an answer to this question)
Responder | Letter spacing in style attributes is not important | Comments |
---|---|---|
John Foliot | I approve of the rule being published | |
Laura Carlson | I approve of the rule being published | |
Gregg Vanderheiden | ||
Rachael Bradley Montgomery | ||
Oliver Keim | ||
Gundula Niemann | ||
Wilco Fiers | ||
Jeanne F Spellman | I approve of the rule being published | |
Jaunita George | I approve of the rule being published | |
Bruce Bailey | I approve of the rule being published | |
Michael Gower | I approve of the rule being published | |
Andrew Kirkpatrick | ||
Jonathan Avila |
The ACT Task Force would like to publish the following rule:
Word spacing in style attributes is not !important
Do you agree with the proposal from the ACT Task Force to publish this rule?
Choice | All responders |
---|---|
Results | |
I approve of the rule being published | 6 |
I approve of the rule being published with adjustments (please comment) | |
I do not approve because (please comment) |
(7 responses didn't contain an answer to this question)
Responder | Word spacing in style attributes is not important | Comments |
---|---|---|
John Foliot | I approve of the rule being published | |
Laura Carlson | I approve of the rule being published | |
Gregg Vanderheiden | ||
Rachael Bradley Montgomery | ||
Oliver Keim | ||
Gundula Niemann | ||
Wilco Fiers | ||
Jeanne F Spellman | I approve of the rule being published | |
Jaunita George | I approve of the rule being published | |
Bruce Bailey | I approve of the rule being published | |
Michael Gower | I approve of the rule being published | |
Andrew Kirkpatrick | ||
Jonathan Avila |
The ACT Task Force would like to publish an update to the Common Input Aspects note. The change takes content that was previously part of multiple rules and moves it into a shared place. The update includes the following two changes:
Choice | All responders |
---|---|
Results | |
I approve of the updated Common Input Aspects note being published | 5 |
I approve of the updated Common Input Aspects note being published with adjustments (please comment) | 1 |
I do not approve because (please comment) |
(7 responses didn't contain an answer to this question)
Responder | Done: Common Input Aspects note | Comments |
---|---|---|
John Foliot | I approve of the updated Common Input Aspects note being published | |
Laura Carlson | I approve of the updated Common Input Aspects note being published | |
Gregg Vanderheiden | I approve of the updated Common Input Aspects note being published | |
Rachael Bradley Montgomery | I approve of the updated Common Input Aspects note being published with adjustments (please comment) | The custom CSS portion is defined in the negative rather than the positive. Using the positive first would, I believe, make it clearer. Something like: The test cases of ACT Rules interested in the CSS styling must be viewed using the default stylesheet provided by the author. [User style sheets](https://drafts.csswg.org/css-cascade/#cascade-origin-user) and changes to the [user agent default style sheet](https://drafts.csswg.org/css-cascade/#cascade-origin-ua) cannot be applied for a valid test case. That said, I will not object to the current langauge. |
Oliver Keim | ||
Gundula Niemann | ||
Wilco Fiers | Alternative suggestion for Rachael: The test cases of ACT Rules interested in the CSS styling must be viewed with the CSS included by the author, and the [user agent default style sheet](https://drafts.csswg.org/css-cascade/#cascade-origin-ua). [User style sheets](https://drafts.csswg.org/css-cascade/#cascade-origin-user) and other custom styles should be avoided to ensure test cases have the expected outcome. | |
Jeanne F Spellman | I approve of the updated Common Input Aspects note being published | |
Jaunita George | I approve of the updated Common Input Aspects note being published | |
Bruce Bailey | ||
Michael Gower | ||
Andrew Kirkpatrick | ||
Jonathan Avila |
The ACT Task Force would like to publish the following rule:
Element with lang attribute has valid language tag
Do you agree with the proposal from the ACT Task Force to publish this rule?
Choice | All responders |
---|---|
Results | |
I approve of the rule being published | 5 |
I approve of the rule being published with adjustments (please comment) | 4 |
I do not approve because (please comment) |
(4 responses didn't contain an answer to this question)
Responder | Done: Element with lang attribute has valid language tag | Comments |
---|---|---|
John Foliot | I approve of the rule being published with adjustments (please comment) | I would prefer to see "Valid" more explicitly defined (as being iso 639.1): "Element with lang attribute has valid ISO 639-1 language <strike>tag</strike><ins>value</ins>" Currently 'Valid' is only inferred due to the current rule language defining *invalid* values: "Assumption: This rule assumes that only [valid language tags][valid language tag] are enough to satisfy [Success Criterion 3.1.2 Language of Parts][sc312]; this notably excludes grandfathered tags and [ISO 639.2][] three-letters codes, both having poor support in assistive technologies." |
Laura Carlson | I approve of the rule being published | |
Gregg Vanderheiden | ||
Rachael Bradley Montgomery | I approve of the rule being published with adjustments (please comment) | Typo only: Inapplicable example 1 has an extra " at the end. Under applicability, stating that this rule does not apply when a language tag is needed but no lang attribute is present would make this easier to understand on first reading. That said, I will not object to the current langauge. |
Oliver Keim | I approve of the rule being published with adjustments (please comment) | value validation may include syntax and semantics. If semantics are checked a reference to the list of values which validate OK may be helpful. Passed Example 4: Although OK for this case, another page may indeed have some text in the <article> tag, so it would be tested OK but fail in other instances of the this page, eg. if the page shows database content. May this sample better fail? |
Gundula Niemann | I approve of the rule being published with adjustments (please comment) | It should be explained, what a valid language tag is. It should also be clarified, whether syntactical or also semantical correctness is tested. Also, I consider some examples as problematic, like a success for language="invalid". A test usually is static, so it doesn't make sense to depend on whether further text is contained. Note that two-letter codes (even with added country code) are not sufficient, see https://de.wikipedia.org/wiki/Liste_der_ISO-639-2-Codes |
Wilco Fiers | I approve of the rule being published | There was a markdown issue, which caused some of the links not to show up. I fixed it today. That should address John concern of not having a link to a definition of "valid". @Rachael: I've created a PR to fix the typo. Regarding applicability; we've been down that road, and got called back from it by AG, who said we were not doing this consistently. There's an almost endless list of things that are inapplicable. We never figured out a good way to decide what to mention, and what not to. Our experience has been that once you do one, you get more and more and more and more notes, until the rule is mostly notes. It wasn't working, so we stopped doing this. @Oliver: The point of this is to push the boundaries of what is, and what isn't allowed. If a setup like this causes no problems, it's not a failure. Even if it causes issues in other pages. It's those other pages that need to be failed, not this one. @Gundula: I'm not sure what you mean with "two-letter codes are not sufficient". Please elaborate. |
Jeanne F Spellman | I approve of the rule being published | |
Jaunita George | I approve of the rule being published | |
Bruce Bailey | ||
Michael Gower | I approve of the rule being published | |
Andrew Kirkpatrick | ||
Jonathan Avila |
The following persons have not answered the questionnaire:
Send an email to all the non-responders.
Compact view of the results / list of email addresses of the responders
WBS home / Questionnaires / WG questionnaires / Answer this questionnaire
w3c/wbs-design
or
by mail to sysreq
.