I believe if we fix the focusable element issue, that should unblock T312294: Add image: Create end-to-end test to verify saved content

Regarding the first item:

Clickable elements must be focusable and should have interactive semantics
figcaption class="ve-ce-branchNode ve-ce-activeNode mw-ge-recommendedImageCaption mw-ge-recommendedImageCaption--with-placeholder ve-ce-activeNode-active"

I believe this has something to do with us making a <figcaption> into an editable element. I think the accessibility standards want it to be a textarea?

I'm having a difficult time testing my changes to confirm that theory with either browser's accessibility checker since getting this section visible requires interaction with a fresh page. Anyone have insight?

Change 938963 had a related patch set uploaded (by KMorgan; author: KMorgan):

[mediawiki/extensions/GrowthExperiments@master] Add section image: Accessibility tabindex change

https://gerrit.wikimedia.org/r/938963

In T336532#9022141, @KMorgan-WMF wrote:

Regarding the first item:

Clickable elements must be focusable and should have interactive semantics
figcaption class="ve-ce-branchNode ve-ce-activeNode mw-ge-recommendedImageCaption mw-ge-recommendedImageCaption--with-placeholder ve-ce-activeNode-active"

I believe this has something to do with us making a <figcaption> into an editable element. I think the accessibility standards want it to be a textarea?

In my keyboard tests I can't focus to none of the interactive elements inside the CERecommendedImageNode: the thrash button, (i) View image details link, caption text area or (?) help with writing. Probably due to the fact we set VEs surface in read-only mode (I think at least that adds contenteditable="false" as an html attribute).

I'm having a difficult time testing my changes to confirm that theory with either browser's accessibility checker since getting this section visible requires interaction with a fresh page. Anyone have insight?

I'm able to test the changes in 938963 with FF without a page reload by starting a section image task and using the Accessibility tab once the caption is displayed. Here's an example:

In general I think the keyboard support in this interface is gonna be tricky to achieve if we don't disable the read-only mode which has it's own problems (users can drag chunks of content by accident, specially o mobile). I'm not sure if VE has a way to choose which parts of the content should be disabled for edition or a way of supporting keyboard friendly read-only content 🤔. Not sure if it is worth asking about this use case to the Edit team, or we have prior research work around this cc @Tgr @RHo

In T336532#9024254, @Sgs wrote:

In T336532#9022141, @KMorgan-WMF wrote:

Regarding the first item:

Clickable elements must be focusable and should have interactive semantics
figcaption class="ve-ce-branchNode ve-ce-activeNode mw-ge-recommendedImageCaption mw-ge-recommendedImageCaption--with-placeholder ve-ce-activeNode-active"

I believe this has something to do with us making a <figcaption> into an editable element. I think the accessibility standards want it to be a textarea?

In my keyboard tests I can't focus to none of the interactive elements inside the CERecommendedImageNode: the thrash button, (i) View image details link, caption text area or (?) help with writing. Probably due to the fact we set VEs surface in read-only mode (I think at least that adds contenteditable="false" as an html attribute).

I'm having a difficult time testing my changes to confirm that theory with either browser's accessibility checker since getting this section visible requires interaction with a fresh page. Anyone have insight?

I'm able to test the changes in 938963 with FF without a page reload by starting a section image task and using the Accessibility tab once the caption is displayed. Here's an example:

In general I think the keyboard support in this interface is gonna be tricky to achieve if we don't disable the read-only mode which has it's own problems (users can drag chunks of content by accident, specially o mobile). I'm not sure if VE has a way to choose which parts of the content should be disabled for edition or a way of supporting keyboard friendly read-only content 🤔. Not sure if it is worth asking about this use case to the Edit team, or we have prior research work around this cc @Tgr @RHo

I'm unaware of research around this but do think it is worthwhile checking with the Editing team, and perhaps Front End group in general. DST has been conducting an a11y audit of Codex components recently as well (see T341493) so they may have some insight to share.

I just noticed that FF accessibility test argues about the color contrast issues in the RecommendedImageNode texts:

• View image details
• Write a short caption describing...

Surprisingly the article text content is also yielding the same contrast issue:

In T336532#9027112, @Sgs wrote:

I just noticed that FF accessibility test argues about the color contrast issues in the RecommendedImageNode texts:

• View image details
• Write a short caption describing...

These seem easy to fix if we get some color specification cc @RHo @JFernandez-WMF

Hiya, can we use for the text-colour @color-subtle (#54595d) instead? Thanks!

Surprisingly the article text content is also yielding the same contrast issue:

I haven't found a VE issue for this, I can file it if we identify this to be an issue cc @RHo and ping editing team.

@KMorgan-WMF, any update on this work? Will you move this to "In Progress" on the Phabricator Workboard if you are working on this?