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

Files: 
CommentFileSizeAuthor
#25 editor_image_alt_required-2297681-25.patch723 bytesWim Leers
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 74,088 pass(es). View
#6 CKEditor-AltRequired-Failed.png62.83 KBmgifford
#6 CKEditor-AltRequired.png54.44 KBmgifford
#6 CKEditor-Config-AltRequired.png61.88 KBmgifford
#5 editor.module-2297681-5.patch1.56 KBcs_shadow
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 73,030 pass(es). View

Comments

Charles Belov’s picture

Issue summary: View changes
Charles Belov’s picture

Issue summary: View changes

Added steps 2 through 10.

larowlan’s picture

Good call

Amber Himes Matz’s picture

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

cs_shadow’s picture

Version: 8.0-alpha13 » 8.x-dev
Assigned: Unassigned » cs_shadow
Status: Active » Needs review
FileSize
1.56 KB
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 73,030 pass(es). View

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

mgifford’s picture

Wow, what a simple & powerful patch. Definitely a +1 for accessibility.

Here's the config screen:
Configuration screen

The CKEditor User screen:
User screen

And failed message screen:
Failed upload

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 Belov’s picture

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

mgifford’s picture

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.

cs_shadow’s picture

Status: Needs review » Needs work
Issue tags: +Needs tests

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

cs_shadow’s picture

Assigned: cs_shadow » Unassigned

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.

cilefen’s picture

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.');
cilefen’s picture

FileSize
2.67 KB
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 73,188 pass(es). View
1005 bytes

something like this

mgifford’s picture

Status: Needs work » Needs review

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.

davidhernandez’s picture

Status: Needs review » Needs work

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

cs_shadow’s picture

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

davidhernandez’s picture

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.

cs_shadow’s picture

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.

Wim Leers’s picture

Title: Allow requiring alt text for wysiwyg image » Add setting to make alt attribute required in EditorImageDialog

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

larowlan’s picture

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

davidhernandez’s picture

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

cs_shadow’s picture

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

mgifford’s picture

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.

Wim Leers’s picture

  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.

mgifford’s picture

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

Wim Leers’s picture

Title: Add setting to make alt attribute required in EditorImageDialog » Make the "alt" attribute required in EditorImageDialog
Status: Needs work » Needs review
Issue tags: -Needs tests +CKEditor in core, +Spark
FileSize
723 bytes
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 74,088 pass(es). View

Et voila. Super simple patch :)

cs_shadow’s picture

Looks good. +1 for such a simple patch.

davidhernandez’s picture

Status: Needs review » Reviewed & tested by the community

Works for me.

Charles Belov’s picture

Title: Make the "alt" attribute required in EditorImageDialog » Add setting to make alt attribute required in EditorImageDialog

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

Charles Belov’s picture

Issue summary: View changes

Added "This is inconsistent with the Image field." to the original issue.

davidhernandez’s picture

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.

Wim Leers’s picture

Title: Add setting to make alt attribute required in EditorImageDialog » Make the "alt" attribute required in EditorImageDialog

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 Belov’s picture

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

cs_shadow’s picture

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

Charles Belov’s picture

Thank you.

Wim Leers’s picture

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

Charles Belov’s picture

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

mgifford’s picture

Issue tags: +atag
alexpott’s picture

Status: Reviewed & tested by the community » Fixed

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

  • alexpott committed 074bc73 on 8.x
    Issue #2297681 by cilefen, Wim Leers, cs_shadow | Charles Belov: Added...
anandkp’s picture

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.

Wim Leers’s picture

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

mgifford’s picture

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.

Wim Leers’s picture

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.

anandkp’s picture

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)

mgifford’s picture

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.

AndrewEchidna’s picture

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

mgifford’s picture

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.

hanpersand’s picture

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.

mgifford’s picture

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

rootwork’s picture

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

Charles Belov’s picture

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

AndrewEchidna’s picture

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

Charles Belov’s picture

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

davidhernandez’s picture

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.

mgifford’s picture

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.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

undersound3’s picture

mgifford’s picture

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