Resolve TF feedback on "Object has accessible name" 8fc3b6

[carlosapaduarte]

Processing TF feedback in w3c/wcag-act#479

• Added assumption about decorative objects
• Removed SC 1.1.1 from the rule's accessibility requirements
• We couldn't find further ways to add the accessible name to an object
• Tested, with VoiceOver, objects that inject HTML documents. The object is announced as a frame. If the object has an accessible name, VO reads it. If the object does not have an accessible name, but the document has a title, this is read by VO (in Chrome and Firefox) as the accessible name (but the object does not have an accessible name in the accessibility trees). If there is no accessible name nor title in the HTML document, the frame is announced without name. In Safari, VO never announces the accessible name.
• Updated some examples to inject other types of objects (images and HTML documents)
• Fallback content does not generate an accessible name, so I don't think we should promote its use with examples
• Corrected grammatical error
• Update failed examples descriptions with further information

Closes issue(s):

• Object element has non-empty accessible name - grammatical error #1409
• Object element has non-empty accessible name - better explanations in failures #1410

Need for Final Call:

This will require a 1 week Final Call (added assumption, small changes to test cases)

---

Pull Request Etiquette

How to Review And Approve

• Go to the “Files changed” tab
• Here 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” (if you are really confident in the rule) or "Request changes" and click “Submit review”.
• Make sure to also review the proposed Final Call period. In case of disagreement, the longer period wins.

[WilcoFiers]

Instead of removing the mapping, I think we should fix that sometimes this rule is failing the wrong SC. I think the simplest way to do this is to either add an assumption, or exclude objects with certain types of content.

[Jym77]

Seconding @WilcoFiers comment.

[carlosapaduarte]

Updated applicability to consider only image, audio or video resources and reinstated SC 1.1.1

Changes made

[Jym77]

I like that ❤️ It does raise a few questions…

1. Should we have examples with a type attribute?
2. How is the type determined without type attribute? Looks like it is step 8 in the algo at https://html.spec.whatwg.org/multipage/iframe-embed-object.html#the-object-element which is somewhat complex :-/
   The question is especially relevant in "are we sure that the examples are going to be served with the correct MIME type?"
3. Can we add more types to this list (e.g. archives, fonts, …)? This is definitely not needed for the validity of the rule…
   I think it might be worth to add a definition of "non-text MIME type" which would them be easy to update if needed (plus, can be reused, and makes the intention super clear in that rule: "an object which embeds a [non-text][non-text mime] resource")

[carlosapaduarte]

@Jym77 I'll start by addressing question 2 and then 1 (before question 3)

2. I don't think we should dive into the algorithm (similar to what we do with accessible names, for instance). The browser determines the mime type of the resource (in the same way it builds the accessibility tree). I admit I haven't looked into the details of the process, but by looking at the headers in the HTTP response to the request for the object, the mime type is there and it is the correct one for all the examples we have.
   Furthermore, even when I enter an incorrect mime type using the type attribute, I made two observations: 1) the response headers always have the correct type (ignoring what I entered in the type attribute); 2) the browser always renders the object correctly, apparently also ignoring the type attribute.

3. Given the observations above, I don't really think we need to have examples with the type attribute, because it doesn't seem to be used for any rendering decisions.

4. Not sure it that would be useful. SC 1.1.1 addresses non-text content that is presented to the user. Fonts and archives are not really presented to user, are they? And if they are, I supposed they would be presented as text. By including those, we then would have to write the applicability in a way to leave them out.

I'll wait for your input, to understand if you think we still need to change anything in the rule!

[Jym77]

I'm OK with that 👍

Request for further discussion

[WilcoFiers]

Minor issue

Change made

[EmmaJP]

This unusual scenario feels similar to an iframe. Just double checking, but presume for this rule/example it wouldn't matter if the HTML resource was non-text content?

[carlosapaduarte]

It is similar to an iframe (I seem to remember one of the browsers even treating this as an iframe in the DOM).
The rule was revised to be applicable only to images, audio or video mime types. That's why this was moved to an Inapplicable example.
Do let me know if you wish to change your approval!

[EmmaJP]

This seems OK. I've asked a question, but suspect the response won't affect approval.

[carlosapaduarte]

Final call ends October 5

[carlosapaduarte]

Final call ended. Merging