The wysiwyg image dialog does not support requiring alt text. This is inconsistent with the Image field.
Steps, as admin, using default configuration of simplytest.me:
1. Go to /admin/config/content/formats/manage/basic_html
Actual results: CKEditor plugin settings for Image does not include a checkbox "Require alt text"
Expected results: CKEditor plugin settings for Image includes a checkbox "Require alt text"
The following steps can only be done once step 1 has been fixed.
2. In the CKEditor plugin settings for Image, check the checkbox "Require alt text"
3. Save
4. Click Content
5. Click Add content
6. Click Basic page
7. Click in the Body field
8. Click the image icon
Expected result: The alternative text field has a red asterisk (for required) (as well as underlying code that makes this accessible)
9. Browse to an image and upload it
10. Click OK.
Expected result: Get an error message that alternative text is required. The alternative text field has a red outline (as well as underlying code that makes this accessible).
Comment | File | Size | Author |
---|---|---|---|
#25 | editor_image_alt_required-2297681-25.patch | 723 bytes | Wim Leers |
#6 | CKEditor-AltRequired-Failed.png | 62.83 KB | mgifford |
#6 | CKEditor-AltRequired.png | 54.44 KB | mgifford |
#6 | CKEditor-Config-AltRequired.png | 61.88 KB | mgifford |
#5 | editor.module-2297681-5.patch | 1.56 KB | cs_shadow |
Comments
Comment #1
Charles BelovComment #2
Charles BelovAdded steps 2 through 10.
Comment #3
larowlanGood call
Comment #4
Amber Himes Matz+1 for this!
You can require alt text for images added through the Field UI, but if you add an image through CKEditor in the body field, it's not currently required. Could definitely be frustrating for admins who need to require alt text for images to keep their content compliant with accessibility standards and can do so through the Field UI, but not for any images added through CKEditor.
Comment #5
cs_shadow CreditAttribution: cs_shadow commentedAttached is a patch that provides an option to make alt text required.
Comment #6
mgiffordWow, what a simple & powerful patch. Definitely a +1 for accessibility.
Here's the config screen:
The CKEditor User screen:
And failed message screen:
It works great. I do think it would be useful to have tests though. Not sure what all will be required for this to be RTBC, but it seems very close.
Comment #7
Charles Belov@mgifford: Thank you for the screen prints as I'm not in a position to test this.
@cs_shadow: The screen prints show exactly what I would expect.
Comment #8
mgiffordCharles, thanks again for these great reports!
I just tested it on SimplyTest.me. I've added the link. If you've registered there you can test it for 3 hours.
Comment #9
cs_shadow CreditAttribution: cs_shadow commentedAs @mgifford mentioned, this feature will need tests. I'll upload the tests in some time.
Comment #10
cs_shadow CreditAttribution: cs_shadow commentedUn-assigning myself since I'm a bit lost on how to write tests for this as I couldn't any relevant examples to look at.
That being said, I'll be happy to provide tests if someone can guide me on where to start.
Comment #11
cilefen CreditAttribution: cilefen commentedWe are working on these tests at the NJ sprint today. Here is how to begin the tests in CKEditorAdminTest:
Comment #12
cilefen CreditAttribution: cilefen commentedsomething like this
Comment #13
mgiffordGreat that you're involved in the NJ sprint. Just bumping this to the bot.
I tried to drum up some direction on IRC but wasn't able to do so unfortunately.
Comment #14
davidhernandezThe other CKEditor plugin settings didn't exist in the test, so might as well add them. I'll add another patch.
Comment #15
cs_shadow CreditAttribution: cs_shadow commented@davidhernandez though the tests other settings do not exist currently, it might not be a good idea to add those tests as part of this issue. IMO that should be taken up as a separate issue. Nevertheless, I completely agree that the other settings must also have test coverage.
Comment #16
davidhernandezSo, looking into this more, since the image upload component to the form is generated from the editor module and is agnostic to the editor in use, I think the tests should be part of the editor module. If so, than use the patch in #5, and as cs_shadow said, the testing is another issue. Maybe added to verifyUnicornEditorConfiguration()? I'm not* entirely sure how to work on that.
*edit typo.
Comment #17
cs_shadow CreditAttribution: cs_shadow commentedIMO we should use the patch from #5 and add tests just for this functionality and add more tests to the same class/file as a follow-up.
As for the tests itself, we can use something like what's suggested by @cilefen in #12.
Comment #18
Wim LeersImproved the title.
Is there any reason why we shouldn't make this always required? Then we'd be accessible by default, instead of accessible if configured "correctly".
Comment #19
larowlanYep making it required will help us meet atag b4.1.1 http://www.w3.org/TR/2013/WD-IMPLEMENTING-ATAG20-20131107/#sc_b411
Comment #20
davidhernandezAre you saying get rid of the checkbox and force it to be required, or just have it checked by default on installation?
Comment #21
cs_shadow CreditAttribution: cs_shadow commentedFrom what I understand, we just need to have it checked by default. Users may uncheck it if they want.
Comment #22
mgiffordThe application of alt tags should be consistent.
It would be great if this was enabled by default. Mind you it isn't when you create an image as part of a new Content Type.
I do think that alt tags should be disable-able. It would be great if it were enabled by default. However, let's deal with the default state in a new issue.
First let's just make sure we can require alt tags easily in CKEditor.
Comment #23
Wim LeersEditorImageDialog
.alt
attribute on images to be required, because it's necessary for accessibility and ATAG (#19).EditorImageDialog
is a form like any other, those sites that really don't want to define analt
attribute can just alter the form, to set#required = FALSE
, or to even remove it altogether. This does not need to be configurable in the UI, IMO, because the sane default is foralt
attributes to be required.alt
attribute right now, then that's how it is. It's out of scope for this issue. Don't forget that they're image fields, and perhaps these images are never exposed in any way to the end user, or perhaps they're repackaged in an image carousel or whatnot, in which case it may be fine to not have alternative text. But in the case of an image being used in rich text, I don't think there's any non-farfetched reason to not have analt
attribute.In short: requiring
alt
is the simplest solution possible. It's also the good thing to do. Everything else is the 1% case which we don't need to create a UI for.Comment #24
mgiffordAll good points Wim. I'm sold. Really want to see this in Core.
Comment #25
Wim LeersEt voila. Super simple patch :)
Comment #26
cs_shadow CreditAttribution: cs_shadow commentedLooks good. +1 for such a simple patch.
Comment #27
davidhernandezWorks for me.
Comment #28
Charles BelovI respecfully request that "Making the alt attribute required in the Editor module" be a separate issue, related to this issue, rather than repurposing this issue, because:
1. The issue I originally filed needs to be solved whether or not the Drupal community decides to make the alt attribute be required. My original issue had the intent of making the Editor image dialog consistent with the Image field dialog, which currently has a check box to require an alt attribute. Making it required in the Editor but not in the Image field would create a new inconsistency. I regret not making that clear in the original post.
2. If the community decides to make the alt attribute be required, it needs to be resolved consistently in both the Editor image dialog and the Image field.
Comment #29
Charles BelovAdded "This is inconsistent with the Image field." to the original issue.
Comment #30
davidhernandezI think that goes back to Wim's point 5 in #23. The image field and the editor are not the use same use case, so their forms do not need to be consistent. Having it forced on the editor should be acceptable, since the only use is to insert an image with an html tag, which should always have alt text.
Comment #31
Wim LeersI can't add anything to #30.
The key problem is to ensure that images have
alt
attributes, yielding a consistent UX for the end user; not that the back-end configuration UX as seen by the 0.1% is consistent.If you want the configuration UIs to be consistent, then please create a new issue for that. That will have the "minor" priority.
Comment #32
Charles BelovWith regard to #23.4
Since EditorImageDialog is a form like any other, those sites that really don't want to define an alt attribute can just alter the form, to set #required = FALSE, or to even remove it altogether. This does not need to be configurable in the UI, IMO, because the sane default is for alt attributes to be required.
Can the form be altered without hacking core? That is, can it be overridden in the /sites directory rather than directly?
Not saying that I would set it to FALSE - we're a government agency and actually I'd prefer the default to be TRUE - but I wouldn't want to put someone else in the position of having to hack core.
Comment #33
cs_shadow CreditAttribution: cs_shadow commented@Charles, The concerned module/theme can implement hook_form_alter() to achieve this without hacking core.
Comment #34
Charles BelovThank you.
Comment #35
Wim LeersIndeed :) If that weren't possible, I wouldn't have pushed this issue in this direction, Charles Belov. I greatly appreciate your concern for others though, and I *deeply* appreciate the meticulous detail you're bringing to the Drupal core issue queue. I hope to see you more! :)
Comment #36
Charles BelovThank you Wim Leers. I've just filed https://www.drupal.org/node/2303765 for the Image form, but based on your comments I'm not going to relate it to this issue. Please feel free to relate it if you deem appropriate.
Comment #37
mgiffordComment #38
alexpottCommitted 074bc73 and pushed to 8.x. Thanks!
Comment #40
anandkp CreditAttribution: anandkp commentedSome thoughts about this issue
@mike shared this issue in the Drupal A11y Skype chat and, reading through it, some thoughts came to mind.
To save on time, I'm just pasting in my comments from the Skype chat here.
Comment #41
Wim LeersThe "always ask" option is nice, but requires a
#required = 'preferred'
setting, while we currently only allow TRUE/FALSE. I think what's described in #40 would be better, but it sounds like a nice-to-have. Please do create a new issue for this, so we can do this eventually :)Comment #42
mgiffordHey @anandps - thanks for pointing this out. Null
alt=""
& emptyalt=" "
can be valid (screen readers treat them the same way), but the acceptable use cases for it are pretty minimal, particularly from within a WYSIWYG. See:http://webaim.org/techniques/alttext/#basics
Having that additional check (steps 4-7) would probably require a change to CKEditor wouldn't it? Certainly it should be suggested upstream at the very least.
Comment #43
Wim LeersIt wouldn't require a change to CKEditor, only to
EditorImageDialog
. We use our own dialog; CKEditor is not involved in that at all; we merely instruct CKEditor what to do, and CKEditor tells us what the various attributes of the image are.Comment #44
anandkp CreditAttribution: anandkp commentedThanks for the feedback @Wim Leers and @mgifford!
An example
To @mgifford's point in #42, here's the relevant excerpt from the documentation Mike linked to:
The thing is, if you are an author who understands accessibility, it becomes a truly 50/50% chance that you'll need to add alternative text for an image. Note the second point above, the alternative text to an image can be presented through the context of the image's surrounding text.
This is what I'm talking about. Image's only ever need alt text if they relay actual content on their own. Thus, requiring the alt text will do more harm than good. Think of it from a screen reader's point of view... Here's a simple example:
In the example above, you see something like what a screen reader would read out to the user. As a screen reader user, it sounds like repetition to me. I don't need to know that there is a picture of Tina drawing the tree. I only needed to know that she drew a picture of the tree. In this example, the inserted image serves as decoration only.
I acknowledge that my example above could be contended but the point is that the need for alt text in this example is very much debatable and needs to be dictated by the author's discretion.
Proposed change
Disable alt text checks
.You have not provided any alternative text. Insert image anyway?
Yes
andNo, add alt text
.User actions:
Yes
button, the image insertion process will complete but it will still add analt
attribute. The alt attribute will be empty though, like so:<img src="..." alt=""/>
.No, add alt text
button, the prompt will close, the image insertion dialog will remain open and the user's cursor will be placed within theAlternative text
field.I hope this all makes sense! I truly believe that this suggestion follows the spirit of the ATAG and WCAG principles more closely.
Many thanks! :o)
Comment #45
mgiffordI really don't think that the literature backs up it being a "50/50% chance". In most cases where images are used, an alt text is useful. I also don't think that most accessibility folks would agree with this "Thus, requiring the alt text will do more harm than good."
This is old, but Jim Thatcher says on alt text: "If an image conveys no information, or is redundant, specify that with null alt-text".
I know that there are grey areas.
http://www.userfocus.co.uk/articles/alt_text.html
And there is inconsistency.
http://osric.com/chris/accidental-developer/2012/01/when-should-alt-text...
But nobody is complaining that the presence of alt text on images that are descriptive is a common accessibility problem:
http://desarrolloweb.dlsi.ua.es/web-accessibility/comparison-common-web-...
http://www.unimelb.edu.au/accessibility/training/top-ten.htm
EDIT (adding this link) - http://w3c.github.io/alt-techniques/#secm3
I do agree though that having a confirmation message as you suggest would be better. We just need to have someone develop the JS.
Comment #46
AndrewEchidna CreditAttribution: AndrewEchidna commentedMy 2 Cents: I would propose we require alt text for all images in CKEditor and provide a checkbox interface in cases where the editor makes a conscious decision to omit alt text - which I believe should be a rare occurrence. Checking the "Omit Alt Text" checkbox would be the editors was of specifying a null alt text be used in the markup.
This requires the editor make one extra click in the rare case that alt text is not required. Checking the box would disable the alt text input.
Utilizing this checkbox would output the null format alt="".
Comment #47
mgiffordI like that.. That extra click might well be what makes the difference between someone taking the time to type in a description & just figuring nobody would care about it....
Gives the user the right to override it in the interface.
Comment #48
Hanpersand CreditAttribution: Hanpersand commentedOne thought I had is that the alt field could be required, but the user could opt to use the
<none>
placeholder (in the alt attribute field that's bundled with the image field, or via CKEditor, or via Insert module field), as is used in Views, Panels, and Blocks when you don't want a title to appear. That could be a more compact way for a user to "opt-in" to an empty alt attribute.Comment #49
mgiffordIn Drupal the
<none>
"tag" is pretty well understood as you mentioned on Twitter.Comment #50
rootwork@hanpersand I like that proposal too.
<none>
makes sense.Comment #51
Charles BelovI think that
<none>
or any other special syntax would be a challenge for our staff, who are non-technical. I'd strongly prefer the check box to intentionally omit alternate text, just for usability.Comment #52
AndrewEchidna CreditAttribution: AndrewEchidna commentedPerhaps by hitting the checkbox,
<none>
is automatically input in to the alt text?Comment #53
Charles BelovThat would work for me. The advantage is that if
<none>
is stored in the database, it's affirmation that it was intentional, as opposed to empty which means it's legacy content without alternate text. And yet it does not require any technical expertise.Comment #54
davidhernandezThis issue has a committed patch and is marked fixed. Please open a new issue to discuss other changes. Other people aren't likely to look at this one anymore.
Comment #55
mgiffordThe improvements to this have moved over to #2307647: [Follow-up] Allow manual override of required image alt text in the Text Editor image dialog when appropriate. Thanks for the reminder @davidhernandez.
Would be great to have folks chime in over there too. I know @anandps tried to capture all the points that have been made here.
Comment #57
undersound3 CreditAttribution: undersound3 commentedComment #58
mgifford@undersound3 - Thanks so much for finding this bug! Hard to believe that error got by so many of us.