[Follow-up] Allow manual override of required image alt text in the Text Editor image dialog when appropriate

Interesting! We should definitely look into this. I am moving around some of the meta data, since this isn't a bug - its a feature to comply with ATAG. Since we only require to comply with WCAG 2.0. It's also definitely not major, compared to other accessibility fails we should fix before release.

I wonder if we can go with a simpler interaction and only going with the replacement pattern . I don't like interactions having both a checkbox and a field, that have the same functionality, that will make for a more confusing interaction. Using is a understandable pattern, and something we can explain in a small help text.

I don't think we should a confirm box on things like this ever, although it is bad that people choose options that make their site less accessible. It does not break their website. Confirm dialogs should be reserved to things that truly and utterly break their website if done incorrectly, like removing an item like a node/menu/module (we have no undo). Although I understand you want to educate them, by trowing an confirm dialog on a concept that for your ordinary content creator will be hard to understand - you instead only confuse them more.

Bojhan already wrote the majority of the concerns I have.

I'll just ask a simple question instead: can you give a real-world example of where this would be necessary in, say, an article's body? Decorative images is not an acceptable answer, since they belong in CSS, or at the very least they don't belong in an article body.
It'd be a huge violation of the separation of concerns. It'd break content reuse.

It'd be a huge violation of the separation of concerns. It'd break content reuse.

1. Separation of concerns: HTML = structure + content. CSS = styling.
2. Content reuse: the content continues to work just fine after the theme has been changed, because the content is free of styling information that is theme-dependent/specific. The content can also be consumed in other representations, such as JSON, XML, PDF … and does not contain bizarre artefacts for one representation (HTML with a certain Drupal theme) in those other representations.

In the least, well formed and descriptive helper text that explains why it's important is my greatest concern. Aiming for a standard like ATAG by making alt required without spreading knowledge at the same time seems to be contradictory. Like telling interrupting a person as they speak without offering any explanation.

While I'm very grateful for the mock-ups you've provided, I fear they very clearly show the problem with adding descriptive helper text: they make the UX unnecessarily complex.
I'd even go further and ask: why does every user need to understand every nitty gritty detail about HTML if the UI/UX automatically guides him/her to build correct, accessible HTML?

I'm sorry, but I asked for a real-world example in #3, and still haven't seen it. I've yet to see images that are used as visual aid in content that don't need alternative text. Until then, I fear we'll be arguing in circles about insufficiently concrete things.

I don't think that is a good example. They aren't using the alt tag correctly, as the text there has nothing to do with the image. Their system probably programmatically uses the same text as the lead, because the editors didn't/didn't want to enter separate alt text.

A very real-world example is an image that has a caption that serves the same purpose as the alt text would.

Yes, images that serve as content generally should have alt text. However if the alternative text is already provided in figcaption, for example, that isn't necessary, and is in fact harmful.

It is also definitely possible to have decorative images in the content area. Decorative images don't have to just be gradients. They can also be images that provide visual interest, but don't serve a content purpose where alt text would be appropriate.

You can put numerous accessibility people in a room, and they're likely to argue about which images require alt text and which should have none. Drupal deciding that each and every image that is ever inserted using WYSIWYG must have alt text is likely to be wrong in at least some circumstances.

I'm not sure if all the pop-ups and alerts are necessary, but there should be ways to insert images with null alt text, even if we advise against doing so.

In issue description item 3 (as opposed to comment 3):

It would be helpful for the first screen print to be explicitly labeled as content editor's view and the second screen print to be explicitly labeled as the admin's view. I initially took them both to be the admin's view.

With regard to the link "When to provide empty alt attributes". It currently goes to http://www.w3.org/TR/WCAG20-TECHS/H67.html. However, the link target provides how, not when, to provide empty alt attributes. Therefore, it appears not to be suitable as helper text.

I do feel there does need to be something, whether <none> or something else, to explicity indicate that alternative text has intentionally been made empty in order to distinguish it from legacy data in which alternative text was unintentionally forgotten.

First @anandps thanks for your detailed follow-up issue summary. Very useful, and difficult to summarize a thread of discussions.

This is definitely an ATAG issue, but it is also a WCAG issue. There are times when having an empty or null attribute is the right choice for accessibility. This doesn't happen incredibly often, but for decorative images it is something that a content author will need to do from time to time.

This is something I don't know any other CMS has grappled with. Not something new for Drupal. Sadly the requiredish pattern isn't something we can lean on.

I changed the title to highlight that it's a follow-up issue and also to focus on the manual override aspect.

@Bojhan I hear your call for a simpler interface. <none> is a great pattern that many Drupal folks know, which would simplify things, but unfortunately, not most content editors.

Possibly we could just have a modal that asks folks to confirm that they want a null/empty alt attribute. We don't have a pattern for a required element that can be over-ridden, but that's really what's needed.

@Wim Leers - content authors generally don't have the access to put images in the CSS. Web accessibility guru @stevefaulkner kept pointing me to a useful W3C document on Using an empty alt attribute alt="". The two that are most relevant to the body of a message are:

• An image consists of text that is repeated as text or a graphical symbol whose meaning is conveyed as text, immediately before or after the image.
• The image is included as the content of a link and there is text content included that clearly describes the link target.

@anandps - odd about <none> - somewhere that should be documented... Another todo....

I don't agree with this statement - "allowing for NULL alt text is mandatory and not providing this ability would be as bad as not asking the user for it at all." - but there are certainly cases where NULL/EMPTY alt text would be more appropriate than some random text that a screen reader could know to safely skip. The larger problem is users not having alt texts, although there are enough instances where a content author would be better being able to at least insert .

@mdrummond - actually from the W3C:

Circumstances in which it is not appropriate to use an empty or null alt attribute: An image is contained within a figure element and has an associated caption provided using the figcaption element. Using an empty alt attribute hides an image from some users. If an image has a caption the image needs to be discoverable by users, otherwise a caption is present that refers to nothing for some users.

A user needs to describe the image that is being featured in the figcaption.

But ya, there definitely "should be ways to insert images with null alt text", in a way that encourages folks to verify that this is the right choice for the image.

@Charles Belov - I made the change to the summary. Seemed simple enough.

Also, agree that it's the content which has "intentionally been made empty" which is useful to markup. Imported data, or folks who use the source code can still override this. It's only when you use the WYSIWYG that this required field is enforced.

@mgifford: Thanks for the clarification. I had misunderstood that particular markup pattern.

A very real-world example is an image that has a caption that serves the same purpose as the alt text would.

Thank you — that's a great point!

Therefore, I understand and agree with:

Yes, images that serve as content generally should have alt text. However if the alternative text is already provided in figcaption, for example, that isn't necessary, and is in fact harmful.

Fortunately, we can easily automate this :) We can make the caption filter strip the alt attribute if a caption is defined!

But if I read #13 correctly, we don't actually want to do that?

content authors generally don't have the access to put images in the CSS.

Indeed. And for a good reason! Content authors are not supposed to do any decoration!

This is why I've kept asking for a real-world example of "decorational images" added by the content author. This is only a valid use case in page-centric CMSes, where you build a complete page (i.e. the modern day versions of Microsoft Front Page). It's not valid in content-centric CMSes, like Drupal.

The canonical example provided by the W3C also shows this: http://w3c.github.io/alt-techniques/#a-purely-decorative-image-that-does... — they provide this example:

<header>
<div><img src="border.gif" alt="" width="400" height="30"></div>
<h1>Clara's Blog</h1>
</header>   

This is the equivalent of a default Drupal install's Druplicon at the top of the page. I don't think any of us would argue that a content author should be able to create that.

Now, I know that some sites will want to "build pages in a node body" anyway, no matter how wrong that is. But that doesn't mean Drupal 8's UX should be made inferior just to accommodate that extreme minority use case (that implies abusing Drupal). Those sites that really want this, should create a module that alters EditorImageDialog's form.

Now, if anybody can finally provide a valid real-world use case for decorative images, then that changes the discussion. But so far, I've only seen arguments that are inapplicable to Drupal, because Drupal is not a page-building CMS.

If I write a blog post about gardening, insert a generic picture of a garden, making no reference to the image in my writing, and its content is not specific to anything in my post, would that considered a decorative image?

@Wim Leers - Thumbs up, this is great! It's again an interesting discussion to find examples. So much of the W3C's thinking is geared to static web pages rather than within a CMS. A more generic example would be good. You've definitely got valid points (as usual). I do think that the icon in this post describes how:

An image consists of text that is repeated as text or a graphical symbol whose meaning is conveyed as text, immediately before or after the image.

Going down a bit further 1.18 Logos, insignia, flags, or emblems - The use of a logo next to the name of the organization it represents does not need an alt text: <img src="images/webplatform1.png" alt=""> WebPlatform.org

I try not to use decorative images myself. @davidhernandez I think I would want to describe the photo in that instance. I'd be passionate about this being my garden, or in late August, or it being just lush and green.

It's an interesting discussion indeed :)

I'm glad you consider my arguments valid. Yours is also valid, especially now that you can back it up with a clear W3C example. But… as far as I can tell this is the only example to be found in all of the W3C specs and all of the real-world use cases (for content-centric CMSes).

If I actually read what the W3C spec you linked to says:

If a logo is being used next to the name of the entity it represents, then the logo is supplemental. Include an empty alt attribute as the text alternative is already provided.

<img src="images/webplatform1.png" alt=""> WebPlatform.org

Then I think this sort of content (a thing's logo with the thing's name next to it) is an extremely rare thing to occur. The only use case I can possibly think of is something like this:

<h2>Event sponsors</h2>
<ul>
<li><img src="a.png" alt=""> Company A</li>
<li><img src="b.png" alt=""> Company B</li>
<li><img src="c.png" alt=""> Company C</li>
</ul>

How often does this happen? I would argue that in almost all cases, the company name would not be listed in text next to it (hence a non-empty alt attribute would be necessary), just the logo would be shown, or there would be a slideshow of logos, or a grid of logos. Almost never, we would see the name next to it.

I think this sole example only supports my argument that we're making the standard UX worse for a 0.1% use case (at best 0.1%)!

I sincerely hope we all reach that same conclusion.

It may be rare to have a need for an image with no alt text. In the vast majority of cases, an alt text is absolutely necessary. But setting up Drupal 8's interface to make it impossible to provide empty alt text in the content area is going to lead to problems.

Here are links to a few use cases where empty alt texts are the right choice:

1. http://w3c.github.io/alt-techniques/#a-graphical-representation-of-some-of-the-surrounding-text-1
   This is the image that sets a mood sort of image. There are definitely cases where this requires alt text. There may be a few that don't.
2. http://w3c.github.io/alt-techniques/#a-purely-decorative-image-that-doesn-t-add-any-information
   This is the border sort of use case. Probably shouldn't be in the content area like this, but people do crazy things.
3. http://w3c.github.io/alt-techniques/#icon-images-1
   Icon images where accompanying text already states what the image is
4. http://w3c.github.io/alt-techniques/#logos-insignia-flags-or-emblems
   Logo where accompanying text already states what the logo is

It's not fun to design for edge cases, particularly when they make the interface more complicated. However I think that's the right call here. Make it difficult to set empty alt text, fine, and make it clear why that might be the right option.

But making empty alt text impossible? I guarantee that's going to cause some issues from time to time.

Lest anyone suggest automatically adding <none> to the alt tag if a caption is provided, I think http://w3c.github.io/alt-techniques/#hf gives a poor example. It shows an image with either alt text or a caption reading: Shadow like figures and a graffiti tag drawn on the walls of a
partially demolished building, illuminated by the light from a street lamp (photo)

However, the caption is overly wordy. I could see co-existing alternative text of:

Shadow like figures and a graffiti tag drawn on the walls of a
partially demolished building, illuminated by the light from a street lamp (photo)

and a caption of

Drawings on the walls of a
partially demolished building.

Not trying to micromanage the particular example. Just saying that you might not want to put everything into a caption that belongs in alt text for the same image.

@Wim, also my Thumbs up example in #17 is a totally legitimate use of alt="".

Also, I look forward to hearing back form Steve Faulkner when he's back home & at work.

But ya, we've got to be able to discuss this. Love that we're able to have these dialogs in this space!

Again, another legit use of alt=""

#19:

But setting up Drupal 8's interface to make it impossible to provide empty alt text in the content area is going to lead to problems.

This is an incorrect statement. You can easily make this possible using hook_form_alter().

1. Indeed, this should always have a caption.
2. People indeed do crazy things, but if they're doing this sort of crazy thing, do you think that it's going to matter if this exceedingly exceptional and erratic (from a Drupal content POV) use case has alternative text while it in theory shouldn't? I bet that these sorts of sites have plenty of other accessibility (and other) problems anyway.
3. All examples listed there are "UI", not "content".
4. See my response in #18.

#21: Yes, I was thinking about the "smiley/emoticon" use case while writing #18. But ehm… IMG_WITH_ALT SAME_IMG SAME_IMG SAME_IMG… isn't that also extremely far-fetched?

Very much looking forward to seeing Steve Faulkner's feedback!

Wim, I don't get why you're pushing back on this so hard.

Whether it's rare or not, and whether you think it's appropriate for people to put icons and logos into the content area, those things will happen from time to time. Forcing those items to have alt text may well make accessibility worse for users with screen readers. You've been given lots of possible examples, and you've consistently dismissed those examples as not happening very often. Well, yes, they won't happen often, but that doesn't mean they won't happen at all. I would personally consider Drupal to be broken if it didn't allow for empty alt text on images.

What's the reason for all the pushback? Because it makes the interface more complicated?

Because it makes the interface more complicated?

Yes — that's the sole reason. I've been saying that since the very beginning, in this issue, and the previous issue (for which this issue is a follow-up).

[…] you've consistently dismissed those examples as not happening very often […]

I've indeed dismissed most examples. But several were not real-world (they were too contrived) examples, others were invalid in a Drupal context, and the few that are real-world examples that are valid in a Drupal context are extremely rare. And AFAICT, at least mgifford was convinced by my arguments. I could be wrong though :)

All I'm saying is that if we can only find <0.1% use case examples, then let's not encumber the default UI with it. It's trivial to write a "Optional Alternative Text for Images in Text Editors" module, so for the sites that need that <0.1% use case, they can simply install that module. It's always been that case in Drupal: Drupal core provides sane defaults that provide the best combination of features and UX for the 80%, 90%, 99%, and it's up to contrib to provide customizations to go the last bit of the way.

I'm just trying to be very vigilant that we don't make this UI that will be frequently used by >90% of content authors unnecessarily complex. That's all. I'm very sorry if I've upset you along the way — that definitely was not my intention!

Like all of you, I'm very eager to hear what Steve Faulkner has to add. I'm here to be convinced!

Just to be clear, I'm not upset. We're both making our cases, and if I appeared upset, my apologies. I get where you're coming from in terms of not complicating the interface. I'm not convinced that empty alts are so rare as to not allow for them.

One question: when it's checking for empty alts, does it check a space in the alt field? My understanding is that a completely alt is better than a space when an empty alt is the way to go.

If an error is generated when the alt field is left empty, my guess is the next thing people will try is to put a space in the alt field. And if that fails, two spaces, etc.

Heard back from Steve. He's on holiday, but will likely be able to review next weekend.

Re: mdrummond #25

One question: when it's checking for empty alts, does it check a space in the alt field? My understanding is that a completely alt is better than a space when an empty alt is the way to go.

The code simply states #required=TRUE, so whatever Drupal does when it sees #required=TRUE is the answer.

A use case for alt="" that we find quite often is when an image is included as part of a link. If the text conveys the description of the link target, the img alt should be empty, unless it also conveys information about the link target not included in the link text

<a href="blah.html"><img alt=""> link text</a>

I talked about this issue in my presentation yesterday at TCDrupal. The almost required feature is an interesting pattern...

So let's say that we do allow an option for empty image alt text. Can we talk through how we'd make that work in the UI (and possibly on the back end)?

I think we have to scratch out the <none> option. This is valid alt text for this image and I really can't see hard coding a solution that would fail if someone for whatever reason wanted to do this:
" />

Edit... Actually, there might be a good reason to not worry about that since ">" breaks the html....

#32: Well, the user would type <none>, but Drupal would transform that to <none>, which screen readers will read just fine… I think? (This escaping already happens in current HEAD.)

If <none> ends up being the way we go, it's not the end of the world. It will be a rare day that would cause any sort of problem.

I think a combination of option one and three in the summary is probably the simplest way to go, although the help text should probably be shorter than what is suggested. Option two forces a pretty active action in order to have empty alt text, but I would guess that would be more difficult to implement. Option four seems the most complicated and onerous, and due to its reliance on JS could be the least reliable.

So I would probably be fine with one and a reduced version of three. Does that sound doable, Wim?

I still think that this is such an incredibly rare occurring edge case that it's not worth having in core. OTOH I do want Drupal core to be a shining example of accessibility.

So… that leaves me personally with the conclusion let's support it, but let's not allow it to affect the UX in any way. That means I don't want any helper text, because any helper text implies a UX regression.

Furthermore, one important fact hasn't been considered yet: if we go with the "special value" approach, we must take languages into account. Asking a French author to enter <none> will be met with disbelief.

Therefore I propose the following solution:

1. use "" (double quotes without content) rather than <none>, because it's not language-specific
2. no helper text in the UI, but when a user leaves the "alternative text" input field empty, the error message should inform the end user, i.e. not just The Alternative Text field is required. but The Alternative Text field is required — but if you want this image to not have alternative text, enter "" (two double quotes without any content).

That still feels icky, but at least it doesn't cause regressions in the UX that will be perceived 99% of the time.

That seems like a sensible solution. I'd suggest that on the error message when the field is left empty, possibly linking to a page that explains empty alt text in more detail. But yes, keep the message short.

> The Alternative Text field is required — but if you want this image to not have alternative text, enter ""

I'm not sure if there is a good way to word this. At first it looks confusing the a user, thinking that you forgot to include what they're suppose to enter in the quotes.

With that alt text I think this solution will work. Wim, thanks for pushing on this. This does seem like a good approach.

#39: You left out a part. I actually suggested the message to be

The Alternative Text field is required — but if you want this image to not have alternative text, enter "" (two double quotes without any content).

Attached is a patch that implements my proposal of #36. It looks like this:

Suggestion: change wording to “Only in rare cases should this be left empty.”

If possible, link rare cases to http://w3c.github.io/alt-techniques/. Or alternatively we could set up a documentation page on d.o. that describes the very narrow situations in which empty alt text is the right choice.

Personally, I'd like to see the link to http://w3c.github.io/alt-techniques/ always (i.e.: not just in an error message), perhaps in the "#description" to the Alternative text textfield, because a lot of clients I've talked to struggle with writing alt text.

That being said, I think there's real potential for bikeshedding on the exact wording of the "#description" to derail and delay this issue, so I'd recommend we keep @mdrummond's wording for the error (with the link on "rare cases") and discuss the best help text for this field in a follow-up issue.

Agreed with #43. We want to avoid bikeshedding. I'm also not comfortable linking to a *.github.io domain — too likely that that URL will cease to work during the D8 cycle.

I changed the wording in this reroll. (Thanks for that! I'm not a native speaker — so this is most welcome :))

I think this strikes a nice balance.

The inline comments and the description for the editor are both useful.

We can't use <tt> though as it's not supported in HTML5 anymore. http://www.w3schools.com/tags/tag_tt.asp

The W3C is using Github officially, but ya, that could change or Github could change in 5 years. So hard to know. However, rather than pointing to this version:
http://w3c.github.io/alt-techniques/

We could point to the latest published version:
http://www.w3.org/TR/html-alt-techniques/

Knowing that the contents will get moved over there. That's a more stable source to point to and I do think it's worth including a link for editors.

Or create a d.o. page that we control, so we can update to point to the latest information if it changes in the d8 cycle, which is quite likely.

Turns out there is a canonical document at http://www.w3.org/TR/html-alt-techniques/ , but I'd be fine with what @Wim Leers has done in #44 for now.

***

Created #2320111: Better help text for the "Alternative text" field in the Text Editor image dialog as the follow-up.

+1 on mdrummond #46 not just because the article on W3 might move but because it is extremely long. The d.o. (not sure what that means - it's jargon to me - but I assume it has something to do with documentation on drupal.org) page could contain a summary before linking to the W3.org article.

I have a slight nitpick with the section on The figure and figcaption elements. where it gives "Shadow like figures and a graffiti tag drawn on the walls of a partially demolished building, illuminated by the light from a street lamp (photo)." both as alt text and as a caption. I would have used the full version as alt text but an edited version "Drawings on the walls of a partially demolished building (photo)." as the caption. Editorially, I feel the full version is too wordy to serve as a good caption. I will submit a comment to their comments e-mail list.

@Charles, I agree with your concerns about the figure/figcaption. I'd thought that an alt text was required (null/empty weren't valid) if it was within a figure/figcaption so if that's going to be an example, it needs some clarification.

Also, one can post an issue here https://github.com/w3c/alt-techniques/issues

I think @mdrummond was suggesting not an issue but a handbook page, probably a child of https://www.drupal.org/node/464496

But would be good to close this issue and worry about discussing links and what not in #2320111: Better help text for the "Alternative text" field in the Text Editor image dialog

So should we just RTBC what @Wim Leers' done in #44, work on the text in the new issue, which will hopefully point to a new handbook page?

Please remove the please :)

So something like this would address the <tt> & "please".

+ '#required_error' => $this->t('Alternative text is required.<br><em>(Only in rare cases should this be left empty. To create empty alternative text, enter <span style="font-family: monospace;">""</span> — two double quotes without any content).'),

Anything else?

#50: hah, good catch!

#51: <span style="font-family: monospace;">… OH MY!? Let's not do that :D Let's go with <code>? :)

Both fixes implemented in this reroll.

Here's a Before/After photo. I think we're good to go with this! Glad you liked the SPAN Wim :) - I wasn't sure if CODE was styled somewhere and this isn't exactly code, so figured I'd try with CSS.

This is not a feature, more like a task.

Awesome consensus building.

Committed 80ba1c1 and pushed to 8.0.x. Thanks!

Awesome consensus building.

:) I agree.

Great job, everyone! Thanks for all the input! I hope you're all satisfied with where we've landed!