Problem/Motivation
On the edit page for image styles there are several accessibility related issues in the context of alt text, link purpose and focus visibility (WCAG21 SC1.1.1, SC2.4.4, and SC 2.4.7)
alt text (WCAG22 SC1.1.1)
The actual image dimensions on the bottom and the right of the sample images are not directly accessible to screen reader users and could get easily missed.
link purpose (WCAG22 SCSC2.4.4)
First, View actual size is redundant. You have two links with the same link text, but those link texts are missing a context. A screen reader user is unable to distinguish just based on the link text if the link forwards to the original or the derivative image? Second, each sample has two redundant links. Each sample first has the link on the View actual size link and then again on the decorative image.
focus visibility (WCAG22 SC 2.4.7)
You have two preview images. the two are prefixed with a string original (view actual size). but after the focus to the view actual size link you see a focus outline covered in most parts underneath the preview sample image.

Reason is that underneath the image there is a wrapping div containing a link tag as well as the two divs for the horizontal and vertical extent in pixels.
<div class="preview-image-wrapper">
original (<a href="/core/modules/image/sample.png">view actual size</a>)
<div class="preview-image original-image" style="width: 160px; height: 120px;">
<a href="/core/modules/image/sample.png">
<img width="800" height="600" style="width: 160px; height: 120px;" src="/core/modules/image/sample.png" alt="Sample original image" title="" typeof="foaf:Image">
</a>
<div class="height" style="height: 120px"><span>600px</span></div>
<div class="width" style="width: 160px"><span>800px</span></div>
</div>
</div>Steps to reproduce
- go to admin/config/media/image-styles/manage/large
- tab through the page, ideally with a screen reader active
Proposed resolution
It seems to me the view actual size link before/on top of each picture is enough to reach the full sized image. It isn't really necessary to have another link for the image. There are two options to solve this:
- Move the CTA to click for viewing the actual image to the title as text and remove the links from the image labels
- Adjust the image labels to the terminology used in code (Source and Derivative)
- Adjust the alt text to the new terminology as well and add the actual image dimensions
- Make the link in the wrapping div the same size as the image so that the focus outline outlines the whole image and isn't hidden anymore.
Remaining tasks
Update the proposed resolution
Respond to #8
add before/after screens shot to the issue summary, or links.
Review
User interface changes
Before:

After:

Introduced terminology
API changes
Data model changes
Release notes snippet
| Comment | File | Size | Author |
|---|---|---|---|
| #21 | after.jpg | 100.48 KB | rkoller |
| #21 | before.jpg | 98.2 KB | rkoller |
| #18 | update.mp4 | 280.74 KB | rkoller |
| #18 | current.mp4 | 186.5 KB | rkoller |
| #15 | unnecessary-link-after-3273099-15.mp4 | 229.42 KB | chandansha |
Issue fork drupal-3273099
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
- 3273099-a-image-style
changes, plain diff MR !8816
- 3273099-image-style-focus
changes, plain diff MR !9060
Comments
Comment #2
rkollerComment #3
lauriiiThis bug exists in Seven too, moving to the image system component.
Comment #4
tintoThis part is covered by: #2852724: Machine-name field is not effectively hidden from keyboard and screen reader users. It is awaiting (accessibility) review.
Comment #6
tintoImproving the issue summary a bit to improve legibility.
Comment #7
tintoAs there are two proposed solutions in the issue summary, here's a patch for the least severe change (Problem 1 - option 2). It fixes the size of the clickable area holding the image, by making it the exact size.
This patch basically adds a
display: block;to both the parent<a>element to make it the same size as the image, and to the<img>element to prevent the weird whitespace underneath the image.This patch does not address Problem 1 - option 1. If we want to get rid of the clickable image entirely, that would require a different patch, but I thought I'd start with the less severe change first.
Please feel free to contribute your thoughts in the comments. :)
Comment #8
rkollerThanks for updating the issue summary @tinto as well as for an initial patch! Finally got my new computer and local environment setup more or less running so I could test and comment on patches more easily again. quite a few to catch up. :/
I've applied your patch. A few thoughts. I like the idea of just applying a

display:block. Tested in the latest Safari (15.6)and latest Edge (103.0.1264.71). Output is identical. But I wonder if it would make sense to also assign a z-index? Because at the moment the bottom and right part of the focus outline are overlaid by the black extent measures?
And another detail I've noted. would it make sense to add a little more spacing between the original (view actual size) line and the images? because currently in case the
view actual sizelink is in focus the bottom of the outline is hidden in part under the image. applies to edge and safari. but in safari there is another oddity I am uncertain where that comes from. somehow the focus outline is eaten away in part as illustrated in the second image.edge:


safari
about the clickable image and opening a new issue I agree. so far I haven't found or seen any real benefit and purpose of having those clickable images. the user just ends up on a page displaying just a single image without any interface controls or actions to apply. the user has to rely on the browser interface to navigate back. so from a usability perspective that functionality hasn't much purpose or benefit from my understanding. and as a positive side effect there wouldn't be the need to take care of the current focus issues for the links.
Comment #10
mgiffordTagging for 2.4.7
Comment #14
jaydeep_patel commentedRemoved link from image and add spacing on top of image so now focus is clearly visible around (view actual size). So now there is only one link to view actual size of image. Attached screenshot(removed_link_from_image_and_focus_visible.png) for the same.
Comment #15
chandansha commentedI have tested MR 8816. Now unnecessary link tag removed.
I moved it to RTBC.
THANKS!!
Comment #16
quietone commentedThis looks like a nice fix.
After reading the issue summary I see that the proposed resolution here has two options. It should indicate which option has been selected and perhaps even link to the relevant comments. This is also changing the UI so there should be before and after screen shots available in or linked to in the issue summary.
There are questions in #8 that still need answers. And I don't see any review of the code changes.
As a reminder, when making screenshot remember to list the steps taken to create them. These should usually be in the issue summary.
Comment #17
rkollerThanks for the reminder and the comprehensive assessment of the status quo @quiteone, I completely forgot about this issue. I took another look. After reading through everything including the recent change I would suggest the following ( in case there is an agreement i would update the issue summary accordingly).
margin: auto. i would suggest to change that tomargin: 0.5em auto auto auto. that way the focus outline for theview actual sizelink is completely visibleand not hidden in part underneath the preview image.Comment #18
rkollerI've played around with it a bit more and came to the conclusion that it would make sense to cover all the three points mentioned in #17 within this issue. i've already have a working copy locally (see the two videos - current.mp4 is the current state without the changes applied, update.mp4 demonstrates these changes). i will hone things a little further and if there are no other issues discuss it at the usability meeting tomorrow to get some more opinions and feedback in regards of the micro copy.
Comment #20
rkollerUsability review
We discussed this issue at #3463918: Drupal Usability Meeting 2024-08-02. That issue will have a link to a recording of the meeting. For the record, the attendees at today's usability meeting were @benjifisher, @rkoller, @shaal, and @worldlinemine.
If you want more feedback from the usability team, a good way to reach out is in the #ux channel in Slack.
In general the group was in agreement with the proposed changes. It was also noted that the newly added keyboard and screen reader related changes are in scope for this issue, since the issue summary already raises the point that there are two redundant links, the
view actual sizelink and the decorative image, for each sample.The
View actual sizelink was in lack of context. A screen reader user was unable to determine when tabbing to the link if the actual size for the "source" or the "derivative image" should be viewed, the link text was identical. My initial idea that i brought to the meeting was to add an aria-label to the link. But the consensus in the group was to remove the link entirely and appendClick for actual imagesto the titlePreview.For the image label there was a clear consensus to move from
Originalwhich is sort of unclear toSource imageand to drop the usage of the image style name which could be quite lengthy in a few cases and go withDerivative imageinstead. At first we were uncertain ifDerivativewould be a too abstract and complicated term in particular for none native speakers and novice users. But for one the image style settings are only available to administrators and site builders aka advanced users, and derivative is the clearest unambiguous term in particular in combination with the termSource. An additional plus the terminology used in code becomes inline with the user facing micro copy.The group also agreed on altering the alt text further and adjust it to the new image label terminology plus adding some punctuation to the newly added width and height values.
Comment #21
rkollerIn regards of the remaining tasks, the usability review in #20 covered the questions raised in #8. I've also added before and after screenshot based on the recents changes from the usability review. And i have updated the issue summary accordingly (removed "problem 2" and adjusted the problem section as well as the proposed resolution section)
There are two open questions:
To those more familiar with tests, i've managed the MR pass the linters but it is failing tests. But i am not sure if the failing of tests is because of one of my changes (in the context of php i've only changed the micro copy and not actual code) or something completely arbitrary? If someone more familiar with tests could take a look please? Therefore I keep the issue at needs work status.I reran the test and the MR passes nowComment #22
rkollerand adjusted the title since it wasnt reflecting the actual scope anymore properly.
Comment #23
rkollerin regards of #21.2 i've asked for feedback on the #accessibility channel and @mgifford thought 21.2 shouldnt be a problem. so i am setting the issue to needs review
Comment #24
rkollerJust rebased MR9060 to fix a problem that lead to an error checking out the feature branch. for reference the error is caused by a spelling fix committed in https://git.drupalcode.org/project/drupal/-/commit/8b368d712d83900765744... that is causing the error on non case sensitive file systems like for macos in my case.
Comment #26
smustgrave commentedDefinitely agree it's a cleaner look
Focus appears to highlight the entire link.
Checked the alt text and definitely more descriptive.
Going to mark
Comment #30
nod_Committed and pushed 843bf350040 to 11.x and 82984b589f5 to 10.4.x. Thanks!