Better help text for the "Alternative text" field in the Text Editor image dialog

Now that #2307647: [Follow-up] Allow manual override of required image alt text in the Text Editor image dialog when appropriate has landed, I think we can do this one.

Having read http://www.w3.org/TR/html-alt-techniques/#intro_alt again, I propose something like this:

Short description of the image, for visually impaired users.

… as the placeholder attribute on the input[type=text] (which makes sure we don't negatively affect the UX: this doesn't consume screen real estate, and it goes away as soon as the user enters alternative text).

I know it's not only for visually impaired users. But that's the primary audience, I think, and most likely a good way to help convince the author to provide a good text alternative.

I really like the idea of putting more of these texts in the placeholder. However I am not yet sure about committing to this as a standard for core. I imagine CKEditor is a good place to try it out though.

I do think that placeholders should have like a max of characters related to the input size. Because it should really be scanned VERY quickly, and not be information that is required to fill it out properly (e.g. information about using should never be in a placeholder) - since it is removed as soon as you enter something. In the many usability tests I saw placeholders, it was very hard for users when this held any critical help text and they often do not know how to get placeholder information back.

For the help text I propose making it shorter, for example:

Alternative image text
[Description for visually impaired]

So Bojhan proposed changing the placeholder text from

Short description of the image, for visually impaired user.

to

Description for visually impaired

I'm fine with "as short as possible", but I think visually impaired is less clear than visually impaired users. I also think it's important to stress that it should be a short description. So what do you think about the following?

Short description for visually impaired users

Or better yet:

Short description for the visually impaired

Let's see how that stacks up against translations (length-wise):

• EN: Short description for the visually impaired
• NL: Korte beschrijving voor slechtzienden
• FR: Description bref pour les malvoyants
• DE: Kurzbeschreibung für Sehbehinderte
• ES: Breve descripción de los discapacitados visuales
• IT: Breve descrizione per i non vedenti

I think that works pretty well? :)

#7: No, please don't add a #description. Not here, nor in another issue. Sites can do that if they want through a custom (or contrib) module. Core shouldn't do that, because it deteriorates the UX. That's why I wrote what I wrote in #1.

I love @mparker17's idea in #7. I feel it meets the needs of ALL Drupal users regardless of experience level (i.e. whether they know PHP, HTML, just how to use a WYSIWYG editor or none of the above).

We don't have a pattern for help links at this point.

I do think it would be worth having a link in the ui to a d.o page we can control with information to help users understand this better.

A short placeholder is definitely important, but we can't put links in there. The text there is fine, though.

Having the link in somewhere like here would be ok - #2308515: Document accessibility features in CKEditor

Understand the concerns of cluttering up the UI.

Reroll, with #3/#4/#5 implemented.

I am trying to see if we can achieve a balance here. I don't know if any other CMS's have patterns we can borrow from.

Alt text really is the low hanging fruit of accessibility, but even here there are complications and mis-understandings. Having a gentle reminder of what meaning a user gets out of an image is important and regularly overlooked.

If #1971222: Incorporate longdesc into image support gets in at some point, it will also need to be clarified with regard to screen readers.

There is a good use case for this being an exception and having descriptive text with a link here should be seriously considered.

#12: I'm not sure what you're saying? Are you advocating for having a link in the dialog (the one in the screenshot in #11) to a lengthy explanation of what constitutes good alternative text?

Basically yes. I do think something like this would be better for accessibility.

I do understand the problems with cluttering up the UI, but do think that providing help text to a page like https://www.drupal.org/node/2324781 could provide users with more clarity about how to write more accessible content.

Many less technical users are going to get stumped about what alt text is and how to provide something in here for a type of user they've never considered before.

I don't think it's Drupal's responsibility to teach end users best practices. It's Drupal job to encourage, and insofar as reasonably possible, enforce compliance with standards.

IMHO #11 already encourages users in a gentle way to enter meaningful alternative text. It may not provide a full explanation of how to write optimal alternative text. But any empathic user will want to learn that and find it for him/herself. Any user who doesn't want to bothered with this will just ignore any recommended techniques and will just enter sadfafasf.

The more Drupal tries to do "the right thing" like #14 proposes (because in theory, it is the right thing!), the further it moves away from the "great UX that doesn't get in your way" that Drupal's been trying to move towards. This moves us in the opposite direction of medium.com and the like.

That's my view. I understand where you're coming from, but I'd really like to avoid #descriptions if possible, for the sake of showing only the essential in the UI (i.e. nothing that's mentally taxing or distracting). I think it's possible to keep it as simple as #11 here. With #11, everything is clear, no explanations necessary.

So… do you think the #description in #14 is absolutely essential? At the cost of a worse UX?

Sorry, stepping in a little here. For the sake of progress, lets get this patch in now.

From a usability perspective its still somewhat icky - but far less than loads of help text to describe a unexplainable usecase. Lets not spend another few weeks going back and forth on another description.

Lets create a proper followup, were we discuss to what extend we should follow ATAG and what constitutes as "help on writing accessible content" Drupal should provide and "help on writing accessible content" people should get from other sources. I don't think its a good strategy to make that decision in this issue, and its important to focus on the high-impact parts not introduce this kind of help half-assed on less impacting stuff like image descriptions. I don't think people write completely useless descriptions, so we can get this in now without the additional description.

@Wim Leers & Bojhan - do really appreciate this discussion between accessibility & usability.

Ultimately, what the Drupal Community has agreed to is WCAG 2.0 AA. For this reason I'm marking this (patch #11) RTBC as it doesn't break WCAG & does gently encourage folks to put in alternative content.

When ATAG 2.0 is finalized the Drupal community can decide if this is a goal that we can formally adopt, but at the moment I think all we can do is lean in and consider where it makes the most sense.

I'm not sure where the best place to have a follow-up discussion about ATAG & the CKEditor implementation might be.

Having descriptive text as an option in D8 could be quite useful #1558068: Configure Alt Text Description.

But we should also have patterns that are consistent for this across the board in Core #1885732: Documenting alt and title tags on image fields

#17: Thank you for your understanding!

#18:

1. Let's agree to disagree then, because:
2. Bojhan and I think Short description for the visually impaired already is giving them clues.
3. Given that the dialog already says Insert image and the field that this potentially confused/helpless user is filling out is labeled the Alternative text field, putting them together yields a search phrase like image alternative text how to, which yields https://en.wikipedia.org/wiki/Wikipedia:Alternative_text_for_images as the first result. I think that's a confirmation of my point: any user who wants to go the extra mile, can, with extremely basic skills (reading, extracting keywords, searching for those keywords), already learn more to write the best alternative text possible.

#20: You didn't trouble anybody! These are the kinds of discussions we must have! We just have to weigh all the needs here, which is why Bojhan and I are arguing against your initial proposal. But we are implementing a light version of it, are we not? :)

It'd really be a shame if we'd lose your excellent input. Please continue to do so. But since this is an open source project, we always have to try to convince each other, and build consensus. Sometimes that's easy, sometimes it's hard. I hope to see you again in the Drupal core issue queue in any case :)

Back to RTBC per #17. (Was NW due to a random testbot fail.)

Committed f7532d7 and pushed to 8.0.x. Thanks!