I will add tests in a follow-up, hopefully soon.

some test content

a header

I see the red warning frame around an image with "" alt text, 👍, now, which fixes the "hidden" issue from before.

Ok, using the above as test images and loading in this branch as the extension, I think we need a fix or two:

Scenario 1: OS Preferences > Accessibility > Display > Reduce Motion unset

Scenario 1a: GitHub > Accessibility > Autoplay Motion Sync with system

Result: Autoplaying giphy no controls.
Component: <animated-image> = span/button[aria-label]/span/image[alt] (this is a pseudo-xpath syntax, noncomprehensive of the contents of the component/DOM structure)

I see frame around gif with alt text ✅

• however 🤔 when I navigate to this element with VoiceOver (which is now not in the tab order but must be found by reading the full content, note to feature team), I observe it reads both the alt text of the button and of the inner image.

My alt text revealer on Twitter stacks alt text boxes when this is the case, and perhaps I would suggest doing the same here.

Scenario 1b: GitHub > Accessibility > Autoplay Motion Enabled

Result: Plain autoplaying giphy (image wrapped in a <a> tag) no controls
Component: none = p/a/image[alt]

I see frame around gif with alt text ✅

• it matches the screen reader experience "visited image some giphy"
• I see in the DOM there is no aria-label on the parent <a> tag

Scenario 1c GitHub > Accessibility > Autoplay Motion Disabled

Result: Widget with play and link controls; begins as static image.
Component: <animated-image> = span/button[aria-label]/span/image[alt]

I don't see any frame at all around the gif when it's paused, although it does appear when I activate it 🧐 I see in the DOM that there's an aria-label on the button and an alt text on the image itself.

Secondly, I'm observing the alt text and when paused the alt text in the DOM reads "Play...." and when playing reads "Pause...", however the displayed alt text seems to be off-by-one here.

Perhaps same here as in 1a where we display both aria-label and alt text.

Scenario 2: OS Preferences > Accessibility > Display > Reduce Motion set

Scenario 2a: GitHub > Accessibility > Autoplay Motion Sync with system

Same as scenario 1c = OS reduce motion unset x Autoplay disabled. Off-by-one alt text (play vs pause) and screen reader reads both button[aria-label] and img[alt] text but we only see visible captions while gif is playing, of the previous alt text.

Scenario 2b: GitHub > Accessibility > Autoplay Motion Enabled

Same as scenario 1b = Plain autoplaying giphy, no widget, no controls. Screen reader just reads the alt text as corresponds to the visited link. Works as expected and as displayed.

Scenario 2c GitHub > Accessibility > Autoplay Motion Disabled

Same as Scenario 1c and 2a = OS reduce motion unset x Autoplay disabled. Visible captions don't match SR experience.

Possible solution

I think by displaying both the button[aria-label] and the img[alt] texts in their own visible caption boxes just for the scenario of the <animated-image> component we can resolve these issues.

I wonder what the off-by-one issue is. Maybe the extension does its thing before the widget's in the DOM. I did observe that the widget loaded after the other plain image, so it's possible it's an async action. How could the browser extension anticipate that? I'm not sure.

Looking at the code, I think maybe it would be more clear to fork the logic -- in the situation of the plain gif, treat it like a regular old image same as we always have, and in the situation of the special component look for the two specific descriptions we want to be made visible. Just a suggestion! I'm not sure what closest does but I feel it's not very descriptive of the reason we're looking for these elements. But, that's a tiny observation and it's up to you.

Regarding anticipating the future of permissive aria labels in user-generated content, I think it won't be possible to anticipate the coming changes so maybe it will need work anyway when that time comes.

@andrialexandrou thank you for the amazingly comprehensive review ❤️

Following your suggestion, I decided to separate out the logic for animated-image.

Now we have a separate path for images contained within animated-image from images that are regularly rendered. This will fix the problem of overlay not appearing for animated image players unless played.

I decided not to output the aria-label on the animated player and stick with just checking and surfacing the alt since that alone should surface the relevant information for the user to take necessary action. I don't think the typical extension user needs to know exactly how the animated player is announced. They just need to know that they should provide an alt for the GIF (which ultimately helps the aria-label of the player be descriptive).

Regarding anticipating the future of permissive aria labels in user-generated content, I think it won't be possible to anticipate the coming changes so maybe it will need work anyway when that time comes.

I agree with that!

Mind another look? 🙏

autoplaying gif frames look good

for the animated-image, i observe

• with alt text:
  • when paused, I expect a frame, but I don't see one
  • when playing, i expect a frame with content from img[alt] but i see the button[aria-label] content
• without alt text
  • the size blows up much larger than the viewport
  • when paused, I expect the red frame but don't see it
  • when playing, i expect img[alt] text but i see button[aria-label] content

I put these in "i expect, I see" format to clarify what I understand your aim to be. if I'm wrong, let me know. also I have some questions ab the animated-image development choices, I wonder if we talked sync about it you could answer those for me

some test content

okay, thanks for pinging me on Slack. indeed I hadn't pulled in the latest.

this looks really smooth now. thank you. all scenarios covered, though I did abbreviate my tests this time. I did