-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Image Accessibility Guidance #5205
Comments
I wouldn't be against adding notices, I have a little concern if we add too many, but this is just a few. @afercia what is your opinion on this? |
I think the alt attribute is no longer populated automatically with a fallback, unless I'm missing something. So, if I upload an image with a file name As @desrosj pointed out, this is a good thing. Worth also considering that in a great number of cases, images are purely decorative so they should really have an empty alt attribute I'm not sure if there are still cases where the alt attribute gets populated with the file name. Maybe we should also consider the case where users could inadvertently copy and paste the file name in the alt text field? In these cases, helping users to produce accessible content would be great. Some sort of check could be useful. I'd say at least a check for |
Discussed during today's accessibility bug-scrub, this would be a nice to have, As for the headings hierarchy and the colors check, checking the alt attribute would be a huge improvement for content authoring. Adding the label needs-dev |
Also, a link to https://www.w3.org/WAI/tutorials/images/decision-tree/ could be beneficial. [Edit:] Update: this was added in #14668. |
Another check that could be added is that the alt attribute must be non-empty if the image is linked and no other content is within the link. |
Can we get an update on this issue @joedolson Joe? |
This is still an area that needs work; there are a lot of opportunities for the image block interface to encourage usage of alt attributes or warn of problems that should be explored. |
Thanks Joe! |
I think an important step for moving this forward is to identify exactly what tests it's reasonable for us to perform. We want to do a good job of avoiding giving false positives, as that can just become an irritation for users. I'm going to start a list here of possible tests, to get this started:
|
Thank you for putting together this list. I would be interested in hearing what should be displayed as warnings in the UI; and what should be prevented by WordPress, using code solutions.
What is the best solution here, for the alt to be removed, and the caption used for the image through aria-describedby?
A good next step would be to compare how the different image related blocks handle this, because they do not handle it the same way. Edit: Also it might be best to solve this with, or after, the update of the link controls. |
When selecting background and text colors for a text block, a warning is displayed if the colors selected do not meet the minimum color contrast threshold for good accessibility.
Some similar notices or warnings could be very helpful for images.
Example: in Trac #34636, the decision was made that trying to generate fallback values for an image's
alt
attribute was doing more harm than good. If someone uploaded an image from Facebook, for example, something similar to13692958_640441422776307_2762172099609496084_o
would be used.IMG_2009
is another potential fallbackalt
value if uploaded from a phone. Both are not helpful from an accessibility standpoint.Some checks that first come to mind.
IMG_####
orDSC_####
).An example of a notice that could be displayed:
Your alt attribute is very close to the image's file name. In most cases, this is not a helpful way to utilize the alt attribute.
Very rough idea right now, but wanted to make sure I made an issue for it. I would love to hear from some contributors better versed in a11y if they think this would be useful, and if the proper usage of the attribute could be properly conveyed in a small notice like this.
The text was updated successfully, but these errors were encountered: