Make the "alt" attribute required in EditorImageDialog

Good call

+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.

Attached is a patch that provides an option to make alt text required.

Wow, 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.

Charles, 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.

As @mgifford mentioned, this feature will need tests. I'll upload the tests in some time.

Un-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.

We are working on these tests at the NJ sprint today. Here is how to begin the tests in CKEditorAdminTest:

    $require_alt_text = $this->xpath('//input[@type="checkbox" and @name="editor[settings][plugins][drupalimage][image_upload][require_alt_text]" and not(@checked)]');
    $this->assertTrue(count($require_alt_text) === 1, 'Require alt text checkbox was found and was not checked.');

something like this

Great 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.

The other CKEditor plugin settings didn't exist in the test, so might as well add them. I'll add another patch.

@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.

So, 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.

IMO 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.

Improved 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".

Yep making it required will help us meet atag b4.1.1 http://www.w3.org/TR/2013/WD-IMPLEMENTING-ATAG20-20131107/#sc_b411

Are you saying get rid of the checkbox and force it to be required, or just have it checked by default on installation?

From what I understand, we just need to have it checked by default. Users may uncheck it if they want.

The 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.

1. This is independent of CKEditor. This is a Drupal form, that lives in EditorImageDialog.
2. Making everything under the kitchen sink configurable is bad for UX, and makes people perceive Drupal as excessively complex.
3. The sane default is for the alt attribute on images to be required, because it's necessary for accessibility and ATAG (#19).
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.
5. If image fields don't require the 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 an alt 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.

All good points Wim. I'm sold. Really want to see this in Core.

Et voila. Super simple patch :)

Looks good. +1 for such a simple patch.

Works for me.

I 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.

I 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.

@Charles, The concerned module/theme can implement hook_form_alter() to achieve this without hacking core.

Indeed :) 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! :)

Committed 074bc73 and pushed to 8.x. Thanks!

Some 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.

@mike, the alt attribute doesn't necessarily need to be required, it's discretionary and having a site administrator decide to enforce its requirement can lead to unacceptable alt text. I'm curious, how does one handle that sort of situation?

i'd almost say that, if the site admin wants to enforce the alt attribute, it would be more important for the checkbox to always ask if an alt is needed to explain, here's what i'm thinking...

1. I'm a content editor using WYSIWYG
2. The site admin has enabled "enforce alt attributes" for images
3. i click on the image field and i click "Save" WITHOUT adding any alt text
4. I should see an error that says, "Are you SURE you don't need 'Alternative text'?"
5. I should have two options, a button saying "Yes" and a button saying "Add text"
6. If I click "Yes" then the dialog accepts my discretion as cannon and adds the image with an EMPTY alt attribute {alt=""}
7. If I click "Add text", the popup closes and my cursor is placed in the "Alternative text" field

That is the sort of behaviour that could be deemed necessary for an ATAG compliant CMS.

Mind you, i haven't read through the FULL issue, I'm just voicing my thoughts based upon the first few comments and the actual issue description.

The "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 :)

Hey @anandps - thanks for pointing this out. Null alt="" & empty alt=" " 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.

It 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.

Thanks 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:

Alternative text can be presented in two ways:

• Within the alt attribute of the img element.
• Within the context or surroundings of the image itself.

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:

Breaking news!

Three year old Tina has drawn a picture of a tree! IMG-Alt: Picture of Tina drawing the tree..

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

• Could we please not make the alt text required, ever? Instead, let's make the UI setting for the Editor say, Disable alt text checks.
• Let's then implement a JavaScript update that pops up a prompt saying, You have not provided any alternative text. Insert image anyway?
• The prompt will have two buttons saying, Yes and No, add alt text.

• User actions:

  1. If the user clicks on the Yes button, the image insertion process will complete but it will still add an alt attribute. The alt attribute will be empty though, like so: <img src="..." alt=""/>.
  2. If the user clicks on the 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 the Alternative 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)

I 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.

My 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="".

I 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.

One 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.

In Drupal the <none> "tag" is pretty well understood as you mentioned on Twitter.

@hanpersand I like that proposal too. <none> makes sense.

Perhaps by hitting the checkbox, <none> is automatically input in to the alt text?

This 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.

The 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.

@undersound3 - Thanks so much for finding this bug! Hard to believe that error got by so many of us.