This month we've rolled out new improvements to many of our content templates to ensure the maximum level of accessibility, particularly with how the alt attribute is populated in images served up through many of our templates. For templates such as the Feature Spotlights or our Feature Rotators, we've revised alt attribute inheritance in all templates that serve up images and have devised an inheritance plan to ensure that your images will have an alt attribute — even if you forget to put alternative text in the multimedia component's metadata. While this excludes images that you embed in your General Content component's body text, the list of templates that have been updated is fairly extensive.

But before we talk about the changes that have been made and what you need to know about how alt text is inherited and populated in your content, let's quick talk about metadata.

Alternative text metadata field

When you open up an image — regardless if it uses the schema Default Multimedia or Image, there is a field in the Metadata tab labeled "Alternative text".  In the Image schema the alternative text field is required — we encourage you to use this type when possible, simply because it will force a reminder to put in alt text for that image.  The Default Multimedia Schema does not require the alternative text field be filled in, but we still want to impress upon you the importance of filling this in to ensure more accurate alternative text for our non-sighted users that visit your website.

What is the primary difference between the two schemas? The Image schema was designed to be your go-to schema for use within the website, with the intent to populate the alt text metadata field into our templates.  However with our migration process, most images were brought in using the Default Multimedia Schema which did not have that field.  We have since added the Alternative Text metadata field, allowing you to populate component templates with that value.

It's important to note that when placing one of these images into your General Content body copy, it will not automatically pull in that alternative text into your General Content copy.  You will have to go into the rich text field, select the image, edit its advanced properties, and place the appropriate alt text there.  We're exploring ways to try and make this more efficient, but for now images embedded in rich text fields require YOUR intervention to populate them with the appropriate alt text.

The inheritance model of alternative text

To help make the insertion of alternative text relatively "fool proof", we have multiple layers where alternative text can be acquired from and be overwritten as we move closer to the actual content itself.  This gives you some level of control in what alternative text you want your non-embedded images (images not embedded in rich text fields) to serve up. For most cases, this will be the order of inheritance:

The templates (such as Feature Rotator or Feature Spotlight) will first create a default alt attribute, such as "Feature image for ___" and then insert the Title field of the component. For example, let's say we had a component, where the Title field had the value "Our New Coffee Shop".  A Feature Spotlight template would first create the default alternative text "Feature image for Our New Coffee Shop" as a base-level alt text value. Since the Title field is required in all associated content types, we can guarantee alt text for all of the templates that have some sort of image field (such as the Feature Image or Feature Thumbnail field).

Next, we then look to the image itself to see if there is alternative text in the metadata field.  If there is, we'll take that value and override the initial default attribute that we first created.  Using our example component, if the image had an Alternative Text value of "espresso and a doughnut", the alt text in our Feature Spotlight would instead say "espresso and a doughnut" instead of "Feature image for Our new  Coffee Shop."

For component types that offer an alternative text field (for example the General Content component has a field labeled "Feature image description (used for alt tags or captions)"), we offer a third level of inheritance.  Content types that have a value populated in those feature image alt text fields, that value would then be accepted over the other two previous possibilities.  Going back to our example, if our Feature image description text field had the value "espresso and a doughnut at our new coffee shop", our Feature Spotlight would then finally use that value instead.

Here is a diagram that illustrates this in action:

To help clarify the inheritance, let's consider this scenario.  What if the image still didn't have any alternative text in its metadata field (i.e. it didn't contain the value "espresso and a doughnut")?  The Feature Spotlight would still be populated with the value "espresso and a doughnut at our new coffee shop" because you've got alternative text in the field Feature Image Description.  Why? Because our inheritance model looks at all three levels and will populate it with the item next in line with a value.

What content types support alt text generation?

The following content templates provide three layers of alternative text inheritance, because they support an additional field allowing you to provide an image description:

• Feature Spotlight (with H2 heading)
• Feature Spotlight (with H3 heading)
• Feature Rotator - default dark
• Feature Rotator - default light
• Feature Rotator - overlay dark
• Feature Rotator - overlay light
• Feature Rotator - side dark
• Feature Rotator - side light
• Internal Jumbotron
• Page Introduction - Feature Image (black text bar)
• Page Introduction - Feature Image (white text bar)
• Page Introduction - Jumbo Feature Image (black text bar)
• Page Introduction - Jumbo Feature Image (white text bar)
• Multimedia Gallery Item
• Multimedia Item - inline no text
• Multimedia Item - inline with text

The following content types only provide two layers of inheritance. They do not offer an image description field (at this time):

• Flex Spotlight (with H2 heading)
• Flex Spotlight (with H3 heading)
• Location *
• Personnel Detail *
• Personnel List *

These dynamic content types offer two layers of inheritance:

• Article Detail
• Article List and Detail
• Article List and Detail - No Thumbnail
• Document
• Document List

* Denotes that instead of a title used in the first layer of alternative text, it would use either the name of the location (for the location content type) or the name of the person (used in the personnel content type).

We hope that these changes will help provide an additional level of accessibility to your website, further helping you maintain a high standard of web content accessibility.

If you have questions about these changes, please reach out to me and I'd be happy to answer any questions you have on this topic.