Submodule: Define alt attribute in dialog

Thats only in the WYSIWYG editor. In the rendered view of the node you can stuff anything you want into that field.
That alt is used for the iid in the wysiwyg editor is not a cosmetic thing but rather a technical need.

to change the alt value for the rendered image ( node view ) please have a look at the api theme methods

Please read the documentation (API -> theming). there you also can set the alt tag

Actually we could fix it for the node view thought. What do you expect to be in the alt tag? the title?

Please write a submodule for that, look at the api. shoudl be very easy

First this is a great module.

Second, the ALT tag is important because people with screen readers will hear the description and then know what the image is. Otherwise they'll just hear 'Image' and that's it. For that reason, it's part of a number of Accessibility Guidelines.

Here are a couple of helpful discussions:

• http://webstandards.psu.edu/accessibility/tech/images
• http://webaim.org/techniques/images/alt_text

There is no doubt about it is interesting or important :)

I'm going to echo what that0n3guy said in #3. Is it necessary to hijack the alt tag in the wysiwyg editor, or would it be feasible to move the iid to some other attribute?

Right now I'm trying to get my head around whether it is necessary to hide / replace the built-in image editors provided by ckeditor, etc., per #865674: Make the wiki syntax optional. Right now, if I upload two images in a row, they are going to get alt tags, say "9" and "10". If I open the ckeditor image dialog and change the alt tag from "10" to "9", then suddenly, both images become the same image, because I changed the iid. If I change the height and width using the ckeditor image dialog and save the node, then the image is resized correctly, so in some instances, using the existing img dialogs is safe. It would be even better if the entire dialog was usable.

Now, I imagine that with extra code, it would be possible to move the iid to the class attribute (e.g. class="imagecache wysiwyg_imageupload 0 imagecache imagecache-full iid-10"), and that would be an improvement. Would it also be technically possible to add a new attribute, such as iid="10"?

I understand your comment in #1, that you can put the alt text back at page-render time with your input filter, but I'm wondering if the above is technically feasible. There's no reason that the iid must go in the alt tag, right? It's just there because that was easier than parsing out the class, or other possible solutions?

I would like to add that compatibility with this dialog (the ckeditor image dialog) is important, because even if you remove it from the toolbar, it is still possible to open it by right-clicking on the image and selecting "properties". #6 is a good idea, but I also think it is important to leave the "alt" text in the "alt" attribute, so that using the ckeditor built-in dialog is not destructive.

I'm willing to help and try my hand at a patch, but want to know if you have any pointers or advice on the feasibility per #11 before I dive in.

@greg:

Well actually i guess people get confused here, so i explain:
First, open the api page: http://drupal.org/node/809604

WYSIWYG "editing time":

Rendering done by: theme_wysiwyg_imageupload_render_image_wysiwyg($img_obj, $arguments = array())

A representetive of the image is rendered. It has an ID in the alt tag so on edit the corresponding meta-data can be loaded from the DB.

<img alt="ID">

This can but is not to be allowed to be changed, as editting will not be possible then. I could introduce a new XML attribute, like "wui_id='ID'" but this could make things even worse.

So you actually could change the way it renderes, but you shouldnt.

But in the end, you all mean the "node view" rendering, as thats where it comes to be important for screenreaders

WYSIWYG "node view time":

Rendering done by: theme_wysiwyg_imageupload_render_image($img_obj, $arguments) .. and several others for meta-data and containers

If you like to change this rendering - you are free to do so - because this is open to everybody. Render the image the way you like, set alt-tag to whatever you like. Be aware there is an additional API to add attributes to the image:

- hook_wysiwyg_imageupload_rendered_image_alter($img)
- hook_wysiwyg_imageupload_image_attribute_alter($attributes)

So you dont need to override it.

So what the story for alt tag? Well if you want to add a static value like "thats an image", you can simply use hook_wysiwyg_imageupload_image_attribute_alter or theme_wysiwyg_imageupload_render_image to set it.

But if you want a dynamic field which is an option in the dialog, you have to go the submodule way. Please have a look at the lightbox-integration submodul in WUI. You see how to alter the form, how to save those things in the database, how to load them and later how to use that field as an value in the hook / theme method.

Querstions

There's no reason that the iid must go in the alt tag, right?

Well there is a technical reason, because i know it will be unused till that time. I need "some" field to add the id to. The idea you have wont fix the issue at all, because i can use the dialog to remove the class and here you go - its broken. You cant and wont be able to get the integration level we have with WUY right now, when you dont focus on one dialog. The problem is, some of the dialogs work on html basis and what is worse - storing all data in the html entity. this wont work out. The amount of data ( description?! ) and a lot more things like the "selection" issue force as to use a representitive and use the "full rendered" view during the node-view .
It is technically possible to introduce new xml attributes like iid="ID" but this introduces more problems ( some browser remove those tags due they are html doctype invalid ). And people generally dislike those special not html conform attributes.

I would like to add that compatibility with this dialog (the ckeditor image dialog) is important, because even if you remove it from the toolbar, it is still possible to open it by right-clicking on the image and selecting "properties"

You can remove the image dialog of ckeditor completely using the wysiwyg settings hook, i`ve done that.

Thank you for the explanation. I do understand about the iid and the api doc you referenced, but I don't understand everything about node view mode. Some questions and comments...

The idea you have wont fix the issue at all, because i can use the dialog to remove the class and here you go - its broken.

True, but "don't remove the iid class" is a much more reasonable restriction than "don't edit the alt tag". It would be even better to put the iid in a non-standard html entity, though.

The problem is, some of the dialogs work on html basis and what is worse - storing all data in the html entity.

I'm still trying to figure out how this works. It seems that the standard dialogs can edit some items that wysiwyg image upload knows about, like height and width. When you say storing all data in the html entity, it seems that maybe there is some DOM object that you are editing... not the text of the message. I see how wiu converts its object back into [[]] syntax, but the fact that it does so does not prevent the standard dialogs from seeing the image as an image, so 'node view rendering' must be based on DOM objects referenced via the javascript, yes?

some browser remove those tags due they are html doctype invalid

Do you mean this happens during the node view rendering?

You can remove the image dialog of ckeditor completely using the wysiwyg settings hook, i`ve done that.

Can you also modify the context menu (right-click) of the image so that the wysiwyg image upload dialog comes up when you select "Properties"? Since the standard image editing dialogs are so destructive, it seems like it would be a good idea to document how to completely remove them in the wysiwyg image upload installation guide. (Maybe there are too many editors to make this feasible...)

Just to be sure i get the point.

Is it important to have alt="" set during editing a node?
I expect this not to be needed at all, as node-editing is not "screen-reader" ready at all.

As i dont think this is needed, you can simply add submodule for having an "alt" field in the dialog to add informations there. This wont change te alt-tag in the editor, but when the node gets rendered ( node view ) the alt tag can be set using the theme method.

Well disabling the native-image editor for the most popular editors should be a good idea. TinyMCe is easy, CKeditor is more trick but possible, FCKeditor i dont know.

I don't think that it's important to have alt set correctly during node editing. However, if alt is used for non-standard purposes, such as storing wiuiid, then it is necessary to "quarantine" image editing within the wiu dialog to avoid users hurting themselves.

I'll see if I can find time to help document how to quarantine image editing for ckeditor, but I think it would be even better if it was not necessary to do so. I sometimes help people set up Drupal sites that they will manage themselves, so I like to try to file down "sharp edges" when I find them. Having the ckeditor image dialog enabled w/ wiu 2.x is currently a very "sharp edge".

Documentation note regarding quarantining the ckeditor img dialog, I read this page: http://docs.cksource.com/CKEditor_3.x/Developers_Guide/Dialog_Customization. There is also a little more information in the quoted file _samples/api_dialog.html in teh ckeditor release itself. It's not immediately clear how to wholescale-replace the img dialog with, say, the wiu dialog, but there are examples on how to add and remove elements from the existing dialog.

I dont think its sharp when you disable the dialog.

Its pretty common that you can use 2 different working modules for one task - they intefere. You have to disable one.

Not sure why you are looking how to disable some fields n the ckeditor image editor only - i simply remove the whole dialog ( as i dont need it at all )

No, I agree. I wanted to disable the whole dialog, including from the context menu, but only found the documentation above. Ideally, when you right-click on an image, there should still be a "properties" menu item, but it should bring up the wysiwyg dialog, not the built-in ckeditor dialog. The only way I could tell how to do that would be to replace all the elements in the ckeditor dialog with all of the wysiwyg dialog -- but I imagine there must be a better way.

Open a new issue with that "remove dialog from ckeditor" and i will paste the configuration. It is possible to add the wui to the context menu, needs also some settings in the wysiwyg settings hook.

Lets keep this issue for the alt tag and split the other issues into several topics

In order to conform with Web Content Acccesibility Guidelines 2.0 (WCAG 2.0) images need to have an alt text attribute describing the image. In order to conform to Authoring Tool Accessibility Guidelines 2.0 (ATAG 2.0) content editors need to have the ability to provide an alt attribute for images.

Marking this as a critical bug as it does not conform to ATAG 2.0 and therefore does not generate content that complies with WCAG 2.0.

Please let me know if there is a better issue (sub module?) to mark critical for this issue.

Please read the issue. Thats not a bug, even if it does not forfill the Web content Accesibility Guidlines.

A bug is, when the funcionality is not like it has been defined / supposed to be. I never stated to be 100% ATAG 2.0 compatible.

Its an interesting goal though and stays a feature request until then

Ok, thanks for the further information. Since Drupal Core has adopted WCAG 2.0 and ATAG 2.0 I assumed that module authors would wish to do the same.

@Everett: wysiwyg_imageupload 6.x-1.10 is more compliant; I for one have frozen to that version until things are resolved.

I would love to see people actually helping on this :/

Pretty easy to code, but i cant do all the features myself.

I'm with you in principal, but I have a bunch of other things I need to fix up first (esp. in the drush queue...)

Sure greg, take your time. Iam just calling for help, no rush.

Sorry to jump in here, but I am really new to Drupal so I don't have a lot of the terminology down yet.

Would like to know if this topic is what I think it is about, as again, I am trying to learn quickly enough to comment in the forums when I get stuck.

What I think I see is a patch is needed to display the alt txt when a visitor rolls their cursor over an image on our pages?

The alt text that gets displayed(or read by a reader) comes from the "alt text" field in the WYSIWYG editor when adding an image to the page?

Again, forgive me for being so new, I am trying to catch up to all of you !

Nothing bad on being new :) Welcome in the drupal world.

Actually what you think about is "title", alt is what is shown when the picture is missing or you use a text-browser.

Thanks for that info. I did find what I was looking for, it's the advisory title that is displayed on roll over.

Strange location for it's input on the WYSIWYG, but glad I found it !

Why is it strange? Its in the details form - first input field with the description "tilte". Cant be to hard to guess what it is for :)

Think I just found another reason to show I am new !

I am using CKEditor, not WYSIWYG module, my bad.

Are you actually using the WUI module at all? :)

Look at the screencast or the screenshot to check, how the dialog should look like

OMG, no !

This is the screenshot I looked at from another reply in here: wysiwyg_imageupload-alttext.jpeg

If that's what this thread is about, I am so in the wrong area.

Whoever can, delete all my replies, I have tons of egg on my face right now ! :(

@25

I think that the alt attribute with iid is born for debug reasons.
But in view mode, the alt attribute, should be as the title attribute (for screen reader).

So, in wysiwyg_imageupload.module file, in function

function theme_wysiwyg_imageupload_render_image($img_obj, $arguments) 
...
//comment this line
// $output = theme('imagecache', $img_obj->imagecache, $img_obj->filepath, $inline_args, $img_obj->title, $attributes, $do_getsize);
//and replace it with

 $output = theme('imagecache', $img_obj->imagecache, $img_obj->filepath, $img_obj->title, $img_obj->title, $attributes, $do_getsize);
...

and the alt attribute becomes as title attribute.
I supposed that the 4th argument of function theme was the alt tag ($inline_args is $img_obj->iid).

I hope this is the correct way. I tried it and it seems to work.

In this way the alt attribute is accessible. (without fix module).

WYSIWYG Image upload 6.x-2.9
jQuery Update 6.x-2.0-alpha1
jQuery UI 6.x-1.4 (1.7.x)
Wysiwyg 6.x-2.1 (CKEditor 3.4.2)

@36: perfect.

I just want people to participate and be part of it. I could have fixed this also, but actually help is wished.

Will be part of 2.10 and once again

thanks a lot eletre :)

I remember for some other image upload module - so many of them, can't remember which one - you can use tokens to automatically add Alt text, i.e. add user name, taxonomy term, etc.

Here is a submodule if you want to use

Why i made it instead of using eletre solution?

coz my client wanted no title but still alt text.

Just updated it had few problems with alt text when editing previous image and with default alt.

does anyone know how to just change the file i uploaded?
or do everyone have to make a new post to change there own previous file?

you cannot exachange files - yet. Not by the UI

added to the master