WilcoFiers
commented
4 years ago Here's the ticket for the contrast issues Moe reported: https://github.com/act-rules/act-rules-web/issues/212
Open WilcoFiers opened 4 years ago
WilcoFiers
commented
4 years ago Here's the ticket for the contrast issues Moe reported: https://github.com/act-rules/act-rules-web/issues/212
WilcoFiers
commented
3 years ago Second round of feedback:
I can think of cases where elements have several visible label elements, for example a construct of "Sorting Code" label to the left of a text input with a valid example of input above. In this case, the expectation would be that Sorting code is part of the accname, not the example text. The rule does not seem to cover that case.
A similar case could be the combination of label and placeholder where placeholder should probably be discounted (but would need to be contained in accName) if it is the only way of labelling the control, or a floating label construct.
There may be other scenarios introducing contextual uncertainty what the label is and whether it should be counted as label - as in cases where there is a heading for a pop-up (e.g. a search pop-up) that can be interpreted as a label of the field, but the field itself may be visually labelled by an icon (loupe) and therefore arguably not fall under "label in name". Would we then require the heading to be part of the accName of the field? I think it is a grey area.
Answer: This rule is only applicable to elements that are named from content such as buttons, not to text fields.
Answer: This was discussed, we're going to leave this as is.
[x] Inapplicable Ex 2 - if this is inapplicable because it input is not a widget, please update the explanation. Counter to the given explanation, the Understanding article includes "in the absence of left-side labels, immediately above and aligned with the left edge of each input)" and this should pass.
[ ] would be good to include an image of text in the pass/fail examples.
Answer: This is captured in inapplicable example 4. Images of text are inapplicable in the rule.
Answer: As above, the rule is only applicable to elements where the label is inside the control. Text fields and other elements where the label is outside are excluded from this rule because as pointed out, it can be difficult to determine what should serve as the label for such controls.
WilcoFiers
commented
3 years ago This rule went into CFC yesterday. Should be ready for AGWG next week.
maryjom
Rule: Visible label is part of accessible name Survey results Open issue: https://github.com/act-rules/act-rules.github.io/issues/1458 Discussed in two meetings:
Trevor Bostic
Mary Jo
[x] Pretty sure I saw a PR coming through to add a Passed example 1 where there's no whitespace, and renumber the rest of the passed test cases, so the implementation data will necessarily have to be updated.
[x] Just an editorial change for the description which uses "their" repeatedly which could be difficult to parse. Hopefully I'm not changing any meaning by suggesting the description reads as follows: This rule checks that the text of the visible label for each interactive element is fully incorporated into the text of that element's accessible name. I'm open to other's additional edits.
[x] Editorial change for Background section. Remove "a" from "a widget roles".
Kathy
[x] Passed Ex 4 explains: This button has visible text that does not need to be included in the accessible name, because the "x" text node is non-text content. Suggest using the Understanding 2.5.3 terminology: 'x' is a Symbolic text character (in addition to non-text content).
[x] Inapplicable Ex 2 explanation doesn't explain why it's inapplicable. Is this inapplicable because
<input>is not a widget that supports name from content?[ ]
Under Expectation: ... except for characters in the text nodes used to express non-text content [add: and Symbolic text characters]Moe
[x] Inapplicable example #2 talks about a text field although it demonstrates an email input field. Although one could argue an email input field expects text, it is programmatically different.
[ ] Styling of Input Aspects links does not meeting minimum contrast requirements. When I hover over these links they turn light blue and are difficult to read.
[ ] Styling of Learn more about techniques under Accessibility mapping is also failing minimum contrast. It turns light blue on hover.
[x] Grammatical error: "This rule applies to elements with a widget roles" Remove the article "a". This is plural or make singular.