Why you shouldn';t add text to shapes

The Lectora Help for Adding text to a shape or arrow object states:

“If you do not specify to use an empty ALT tag for the shape or arrow with text, the text for the shape or arrow object is used as the text in the ALT tag. For details about specifying an empty ALT tag for an object, see Using an empty ALT tag for an object.”

This is incorrect. When you add text to a shape, the added text does NOT become the ALT tag for the shape. It appears the developers intended to use the aria-label attribute to make these shapes accessible to screen readers because this attribute appears in the structure of the published HTML code, but it is aria-label=”” whether text has been added to the shape or not.

The question is whether the Lectora developers intended to provide this capability, or is this an example of shabby documentation?

The Lectora Help for Converting a shape to a button states:

“If you do not specify to use an empty ALT tag for the button, the text for the button is used for the text in the ALT tag. For details about specifying an empty ALT tag for an object, see Using an empty ALT tag for an object.”

The passages are identical except that “shape or arrow” is replaced by “button.” This actually works as advertised. The resulting button is properly labeled by the added text. It is not clear to me precisely how that is being done because the structure of the published HTML code for this element also includes aria-label=””.

Do not add text to shapes/arrows and expect them to be accessible to screen readers; however, the simple workaround is to just convert the shape to a button, so the internal text will be accessible to screen readers. If the button has no function, you can delete the action that is automatically added during the conversion process.

The question remains: did the Lectora developers intend to implement the proper labeling mechanism for shapes/arrows, or did someone just copy and paste passages in the documentation not knowing what the very real limitations were? In either case, the documentation should reflect the actual performance of the software. It has always been my contention that the accessibility documentation for Lectora Publisher is very poor. It fails to give course designers guidance in dealing with the numerous pitfalls encountered by the general discussion of the accessibility features presented.