Alt Tags not Showing

Thanks Joe, yes the Empty ALT tags is unchecked.

I tried opening in Lectora 17 and publishing, ALT tags appear just fine.

I am assuming it is an error with how 18 publishes.

Could it be Browser related? Works in some but not in others?

You probably already checked this but make sure Empty Alt Tag is not checked on the properties tab for those objects.

I tried opening and publishing the Trivantis Accessibility Template and same issue occurred. ALT tags are removed in replace of aria-label="".

Screen reader reads the button but ALT tags are removed and show alt=""

This is why I advise not using the current version of Lectora.

This change was implemented for a better experience when using screen-readers.

This was changed for the Lectora Desktop v18.1 release, and for the upcoming Lectora Online release (~Sept 2019)

"Initially hidden text is read when it is shown" is the Feature that went in. When the alt and title (hover text) attribute tags were set the screen readers read the button names three times. Screen-readers work great once we removed the alt and title tags (they read the button name only once).

Hover text is lost, but it is possible to make your own hover text in Lectora if it is absolutely necessary.

Please use this thread to discuss how this change affects you and what you are seeing. Again, the change was done to enhance the screen-reader experience. We do not see this as a bug and ask for your experiences and feedback to help guide any future modifications.

Agreed, client speaks to me like a child - "You need to include ALT tags you know", "Here's a screenshot of where you can select the box". Makes me look like I don't know what i'm doing, spend a whole work day $$ to figure out "it's a feature".

Would be more apparent if "include ALT tags" was not in the publish settings if they are not going to be included.

Thanks @CarlFink you make a good point (more later in the post for you). In this case we made a decision to improve a feature. If this does not improve your published content please help us understand your experience. This change provided what we perceived as a better experience for the screen-readers and environments we test with.

It also allowed for a frequently requested feature to be implemented (reading initially hidden text from text blocks, buttons, and shapes when shown).

We request your feedback by telling us how this change:

a) breaks your content or your content's compliance

b) provides a less preferable experience

c) causes you unwanted rework

We appreciate your feedback and help in improving Lectora. And Carl, we are working on some in application guides that will notify users that something has changed. In this case we really should notify authors when they load an accessible title that the Aria attributes, Alt tags, and Title tags changed for Text, Buttons and Shapes, I absolutely agree with your pet peeve.

@wheels,

Joe, you've just triggered a pet peeve of mine.

DO NOT, NOT, NOT change things silently. Ever. If you're removing a feature (or disabling an underlying HTML capability) do it out loud and don't make your customer do detective work to figure it out. If Lectora is going to override the user and do something different from what it is told (and I'm putting it that way to make it clear how bad an idea I believe that is), then you MUST, MUST, MUST pop up a big, clear, dialog box that says, "Lectora is removing the ALT tag you put into your course because we know better than you." (Yes, I'm doing that on purpose.)

Thanks, Joe. The only thing that triggers me more (as a former software product manager myself) is useless error messages like, "The operation failed." I spent many hours forcing our developers to actually tell the end-user what happened and how to do something about it.

Now that my software designer mindset is active again: to disable the ALT tags is to favor usability for the screen-reading audience over usability for the sighted.

Instead, why not have features for both?

Above, you write, "Hover text is lost, but it is possible to make your own hover text in Lectora if it is absolutely necessary."

So, in an accessible title, have Lectora actually pop up a dialog box that says, "In an accessible title, ALT tags are removed because they interfere with screen readers. Would you like Lectora to display your ALT text as hovertext instead? Yes No".

Easy to code and avoids the whole problem, for 99.9% of cases.

I'm going to review the implementation with the team. I find it hard to believe we couldn't implement the title tag, in another way, or on another DOM element. I also want to see if there is a way to keep the alt tag somehow so to avoid the issue Ryan experienced were people have history with alt tags. We will also run it by the accessibility user group and hopefully get some feedback. Thanks for pointing these problems out.

One thing to note is that is that only IE displays alt tags on hover. The actual purpose of an "alt" ("alternative") tag is to be displayed if an image does not load. The "title" tag is specifically for a hover. Many people using IE are used to the alt tag being displayed on hover, so when they don't see it , they assume there is no alt tag. But that is not necessarily the case; it may be there but not visible on hover, like in Chrome or Firefox. Support for a title tag in Lectora (checkbox on publish?) would be convenient for those used to having others request "alt tags" when they really mean title tags on hover.

See the following link for alt vs title (not an endorsement of this site; it just succinctly explained the issue):

https://www.computerhope.com/issues/ch001076.htm

That said, completely removing alt tags in favor of aria-labels would not satisfy the requirement of having "alternative" text should an image not load, or if a user were using a text-only browser, as some in the accessibility community do.

I just did a quick test using v18.1.2. When I turn off the images in the IE browser, I do see the alt text for my main content image, so that's correct. However, I do not see the alt text for any of the image buttons I've used or transparent buttons or for any controls in the audio play bar. That should be corrected. Alt text displays properly for images and buttons using v16.2.2 when images are turned off, but not for the audio Play and Mute buttons.

@rboyd4570-ok, I have been using some jQuery to augment the HTML output by Lectora v18.1.2. I took a look at setting the title attribute for image and button objects based on their alt and aria-label attributes, respectively. This might be a work-around for you until a formal solution is in place.

1) Open a text editor and copy/paste the following code (comments included to explain what's going on):

//--need to do this to avoid conflicts

$ = triv$.noConflict();

//--this will fire when the DOM structure loads

$("document").ready(function(){

//--a slight delay (1.5 sec) is needed here because the content is drawn dynamically

setTimeout(function() {

//--for every image, set its title to the value of its alt tag

$("img").attr("title", function(){

return $(this).attr("alt");

});

//--for every button, set its title to the value of its aria-label

$("button").attr("title", function() {

return $(this).attr("aria-label");

});

}, 1500);

});

undefined

2) save as a JavaScript file (.js), like my-custom-code.js

3) attach the JS file to your title so it is included in publishing

4) create an HTML Extension object at the title-level. Set Type to Bottom of file scripting (so that it comes after the jquery include that Lectora inserts automatically. Set File to None.

5) Click Edit and add the following line (change to match your filename):

undefined

6) Save and publish your title.

Give it a try. (Sorry, the Forum editor has removed the indentations i included to make the code more readable.)

@mspencer.2813

I just published my test title in v18.2.1 using the code I had posted. It is not working with this version. I'll have to dig a bit to see what changed since I posted my example. Sorry!

UPDATE: Be sure that any smart quotes are replaced with straight quotes both in the code of your new JavaScript file and in the HTML Extension text. That's what caused my recent attempt to fail.

@prg1792, I tried your work-around but it didn't work for me. Perhaps I misunderstood Step 3. Can you clarify how exactly I should attach the js file to my title?

In response to this thread in general:

I really hope Trivantis reinstates the alt-text-as-hover-text in the next update. Or at least give us the ability to designate the title text as alt text so that it will show up in the hover text.

In a course originally developed in Lectora 17, I relied on the hover text as a keyboard-tabbable alternative to image button labels that appeared On Mouse Enter and disappeared On Mouse Exit (since these actions aren't keyboard-accessible). The hover text alternative benefited sighted keyboard users who can't use a mouse.

I'm in the process of making a few minor updates to the course. When I republished it in Lectora 18 (to use the HTML5-only option to ensure no Flash), the hover text disappeared.

While I certainly appreciate Trivantis' efforts to improve compatibility with screen readers, please keep sighted keyboard users in mind as well.

Hi, Monica (@mspencer.2813)

To attach the JS file to your title, perform the following steps:

1. Select the Insert ribbon.
2. Way over on the right, select Attachment.
3. A window will open. Navigate to the folder where you saved your new JavaScript file.
4. Select the file.
5. Select Open.

The JavaScript file is now attached to your title. You can verify this by selecting the Tools ribbon, then Resources. The file should be listed under Attachments/Other.

When a file is attached to a title, it is copied into the root folder of the published files each time you publish. If it is not attached, it is not copied into this folder, and you will get an error message for any corresponding JavaScript calls.

Hope this helps.

@prg1792

Thank you, Ann! I replaced the smart quotes with straight quotes in both the js file and the HTML extension text and it WORKED!!!

Thanks for the script, explanations, clarification, and quick response. It was all very helpful!

You're welcome :-) Glad that worked for you!

*Sigh* This script doesn't seem to work anymore for Lectora 19, based on preliminary testing of another course in SCORM Cloud.

It would be nice not to scour the Internet for work-arounds every time there's a Lectora update.

Does anyone have a fix for the ARIA text or ALT text not showing on keyboard tab for sighted users in Lectora 19?

Great to hear that you got it working again :-)

I will add that it is important to always test any custom code whenever there is a Lectora update. You never know what an update will do.

OK, never mind. I just did it again and it works!

I think I screwed something up by adding a second HTML extension by mistake. Maybe they canceled each other out. So I deleted it and now it's working again.

Thank you again for your quick responses and insights. I do appreciate it!

The browser I need it to work in is IE 11 (yay, government). That's where it worked before.

EDIT:

I'll try entering it manually and see if that fixes the issue.

Hi Monica @mspencer-2813

I manually inserted the code into a course I published with the Lectora v19 Beta. I'll add this disclaimer: since I did not publish using the official v19 application, I cannot say with 100% confidence that my results reflect that tool.

That said, I can see that the code is still correctly taking the alt value (for images) and the aria-label value (for buttons) and setting the title attribute, which is visible on mouse-over. I looked in IE 11, Chrome, and Firefox using the Developer Tools F12 option for each and see that this change has been made.

I am able to see a "tooltip" when moving the mouse over a button or image in all three of these browsers.

But, I only saw the "tooltip" on keyboard focus using IE 11. Chrome and Firefox do not display the tooltip on keyboard focus.

Looking online, I see that the lack of support for displaying the title attribute on keyboard focus is listed as bug for Chromium, with no resolution: https://bugs.chromium.org/p/chromium/issues/detail?id=829352

And another site explains why this makes the title attribute unreliable: https://developer.yoast.com/blog/dont-rely-title-attribute/

So, I'm guessing that what you are experiencing is not related to Lectora v19, but the browser. Could you confirm if you see the tooltips in IE 11 or Edge?

Ok. Here are a couple tests for you to try:

1. When running in SCORM Cloud in IE 11, do the tooltips appear when you mouse-over?
2. Within Lectora, if you preview a page in the IE 11 browser, do you see the tooltips on mouse-over and keyboard focus?
3. If you publish the course as just "Web" instead of "SCORM", do you see the tooltips on mouse-over and keyboard focus?

If the first answer is "no" but the other answers are "yes", then it's possible that the Lectora v19 SCORM wrapper has changed in some way preventing the code from executing when deployed as SCORM.

By request of one of our group members, this topic has been added to the agenda for the October 29, 2020 Lectora Accessibility User Group open discussion.

If the folks who participated in this string - or anyone else interested, would like to join that discussion, please go to www.thelaug.org to add your name to my email distribution list. This will ensure you receive an invitation to our meeting (which takes place the last Thursday of every month (Jan-Oct) from 10:00 - 11:15 Central).

Hi Joe @wheels

The Alt attribute is probably the very first element on the checklist of accessibility auditors -whether we like it or not- in Section 508, ADA, WCAG (2.0, 2.1).

Is it a matter of compromising something for something else? if so, I rather have the Alt attr. rather than the aria-label, but I hope that Lectora 21 can accommodate both.

Accessibility and compliance with the aforementioned standards, have always been promissed to us in Lectora. Is there an intention to bring back the Alt attribute at all, or should we look for it somewhere else?

Hi @malqaseer3753

For images Lectora does include ALT tags when appropriate.

I don't see where ALT tags are required for Buttons, in fact, I see some guidance to not include ALT tags on a Button element. My comment on removing ALT tags was in reference to Buttons.

Can you be a little more specific on where we fail an accessibility audit, if you can include the HTML example that would be very beneficial. We have every intention to make accessibility better, and it is very helpful to have specific examples.

Joe

Hi Joe,

Thank you kindly for your response!

I don't understand why there's that publishing option, "Create ALT tags for images and buttons", if it's not available.

The Alt importance come to play when we have image buttons -- more so, if we have more than one image button that are having the same -or similar- function, on the same page. in this case we need to differentiate and recognize these different buttons.

Mo

The option has been there throughout the years. When checked we do add an aria-label on buttons which is read by screen readers. What is the behavior you wish to happen by setting the ALT tag?

I know an earlier post said that the alt text won't show in Chrome, but is there a workaround for Edge similar to the solution I was previously given for IE above? We're testing courses in multiple browsers now :)

Sorry I didn't attend the open discussion. Is there a recording available or a link to the results of that meeting?

Thanks again.

@mspencer-2813

I started playing with a CSS work-around for showing a tooltip on buttons that get focus from the keyboard, but it's a bit rough. If I can clean it up, I'll share it. Otherwise, it may cause more problems than it solves.

On the bright side, it does look like the Chromium team is moving forward with getting tooltips triggered by keyboard focus as well as mouse hover:

https://bugs.chromium.org/p/chromium/issues/detail?id=829352

I don't know when a fix would be released, but both Edge and Chrome are based on Chromium.

when you hover or use a screen reader after it has been published, the image nor alt tag is being picked up.

What does "it is not picked up" mean? If you are talking about tool tips, it is our belief these should not be used. Here is a link to a little more discussion of the use of tool tips.

Instead we use aria-label to describe Images. These are read by screen readers. Please let us know a little more about what is not working. Is something not available or clear when using screen readers?

@wheels I was about to make a new post on this very topic until I ran across this. The issue is not limited to Chrome. I am using Firefox and alt tags are not showing. Attached are a few pages of the Lectora 19 file where the image name is descriptive and the Empty Alt Tag option is unchecked. Yet, when you hover or use a screen reader after it has been published, the image nor alt tag is being picked up.

Am I missing something in the programming?

@wheels I apologize for not being clear. When you use a screen reader, in my case NVDA, it isn't recognizing the image or reading its alt text (image name). It is just passing it by like it isn't there. Thanks!

Hi @wheels Thank you for your response. I had just published to Reviewlink before seeing your reply. I went back to Reviewlink (using Firefox) and as you verified, it is working correctly.

Thank you for confirming that the Lectora previews do not include alt tags. I thought that was the case, but it is always nice to have it confirmed!

Hi @vicki well I downloaded your project, published and down arrowed through the content using NVDA with Chrome and it read the alt text that is set for the "Estatua de la Libertad y torres gemelas en llamas" image. This did get me thinking about a bug we fixed in v21 though.

A Page Preview (Preview in Browser) does not produce a page with ALT tags. Maybe it's possible you are doing page preview? Try doing a full publish, and at the end do preview. We realize that is less than ideal and it is fixed in v21. Please do let me know if that is the issue. Otherwise, anything more you can tell me about your environment or how you are testing may help me "see" the issue.

Thank you! - Joe

This is a good curated list of accessibility plugins. I don't see any that have that specific behavior, but maybe one of those will work for you.

Is there an HTML extension we can plug in to get the aria-labels to appear when mousing or tabbing over an object in Edge or Chrome? I know they can be read by screenreaders, but I was wondering if there is a way to make them visible as well. I used to be able to plug in an HTML extension that worked in IE, but now that we've switched to Edge and Chrome it no longer works.

@mspencer-2813

I'm still hoping the Chromium bug gets fixed so that the tooltip feature will be a part of the Edge and Chrome browsers going forward. In the meantime, I'll share the work-around that I've been playing with so far. You'll have to test and decide if it's a viable option for you. My title is having some object layering issues, so this isn't a solution for me at this point. I can't guarantee that it will work for you.

I added a class to a custom CSS file for button focus and button hover. They create an object in the DOM after the button to display the aria-label in a small box.

button:focus:after, button:hover:after {
 content: attr(aria-label);
 position: absolute; top: -1em; left: 0em;
 padding: .1em .2em;
 background: #ffffd6; color: #000000;
 border: 1px solid black;
 font-size: 80%;
 z-index: 1000;
}

You can play with the settings to see if this will work for you.

OK, thanks!