SC1-1-1-placeholder-text-is-valid-accessible-name #251

Brynanders · 2018-09-11T13:31:02Z

Closes issue: (#215 )

How to Review And Approve

Go to the “files changed” tab, there you will have the option to leave comments on different lines.
Once the review is completed, find the “Review changes” button in the top right, select “approve” and click “Submit review”.

Valid use of duplicate accessible names

…cate-accessible-name.md

…-1-valid-duplicate-accessible-name-for-image.md changed name and file name to reference "image(s)"

_rules/SC1-1-1-valid-duplicate-accessible-name-for-image.md

+
+## Accessibility support
+
+There is a known combination of a popular browser and assistive technology that does not by default support `title` as an accessible name.


audreymaniez · 2018-09-12T11:09:35Z

_rules/SC1-1-1-valid-duplicate-accessible-name-for-image.md

+```html
+<a href="https://twitter.com/brynanders"> <img src="/twitter_largeicon.png" alt="Twitter"> </a>
+<a href="https://twitter.com"> <img src="/twitter_smallicon.png" alt="twitter"> </a>
+```


I understand the example, but it mixes two elements : link and image.

If we want to keep that example, I think it would be necessary to add in the description, that the links both have the same context, so we can consider the two identical.

In fact, in that example, I think we don't evaluate the accessible name of the image, but of the link, and the accessible name of a link can be evaluate using the context (level AA 2.4.4 Link Purpose (In Context) : see for example the H78 technique (using enclosing paragraph), or H79 (using table context) etc... So, it's not because two links has the same accessible name (made of the alt attribute of the image in our eample) that they are the same, because of the context they may be part of.

@audreymaniez interesting. Are you suggesting that functional images should be non-applicable because they would be covered by #220 ? That would certainly make sense to me.

That would leave informative, complex and groups of images applicable.

That would leave informative, complex and groups of images applicable.

Well, in fact, I think that any kind of images you list (informative, complex...) become innaplicable if the image is included in a link. At the moment, an image is included in a link (complex or not), its alt attribute is not used anymore to describe the image but to give the link a name. And even more : an image that can be evaluated as a decorative one, must have an alt text if its included in a link.

So yes, I think that images, both within a link, with the same alt attribute and the same context, but that lead to different destination is a failed example for the test about identical links #220.

WilcoFiers · 2018-09-13T09:57:04Z

Thinking about it some more, I don't think unique image names in context makes sense. I think what I'd rather us do is rename this. It's kind of hiding its true intent: To catch "default" alt attributes. Duplicate alt attributes aren't a problem. What is a problem, is if you're leaving the default value of an editor in the image alt. E.g. alt="image description".

Instead of suggesting this rule is looking for inappropriate duplicates, lets be explicit that this is testing for default values from authoring tools. I'd even feel comfortable to just look at img elements and alt attributes. I don't think this happens with role=img elements, or with aria-label type stuff.

Adding new paragraph on comparing acc names, that has so far been note in these rules: https://auto-wcag.github.io/auto-wcag/rules/SC2-5-3-label-content-name-mismatch.html #220 #251

Changing rule to address the use of placeholder text by identifying duplicate accessible names.

…d to SC1-1-1-image-accessible-name-has-placeholder-text.md

…md to SC1-1-1-image-accessible-name-is-placeholder-text.md Made significant changes to the rule which is now implementation specific so that authors can determine "placeholder texts" specifically with in reference to the (to be created) "placeholder text" definition.

kasperisager · 2018-10-11T09:28:04Z