Many of our storytellers tell us that producing accessible and inclusive content is a priority for them; likewise, our own Shorthand team is committed to increasing our adherence to the web accessibility principles set out by the W3C Web Accessibility Initiative (WAI).

Because the Shorthand editor produces stories that are designed with accessibility in mind, many WCAG requirements will be met automatically, however the onus is on the creator of a story to ensure accessibility guidelines are met. For example, thoughtful choices will need to be made in regards to the layout, media assets, colour schemes and other custom design elements.

This document can act as a checklist for these accessibility guidelines.

It also contains information on the automatic accessibility features in the Shorthand platform, and lists free web tools which can be used to test various accessibility metrics of a story.

____________

Applies to: Title Section

The Title Section of your story contains the main Heading tag of your document (the H1 element).

The Title Section accepts text in three separate text blocks. The text entered into the first (top) block is rendered in a story as an H1 element.

In code, the H1 tag looks like this : E.g. <h1>Add your title</h1>

Whilst it is possible to omit this heading tag, or even to hide the Title Section entirely (using the Add CSS panel), a missing H1 tag will make a story less accessible.

It serves as an indicator of the main content of the page.

The presence of this element is incredibly important for screen reader technologies that ‘read out’ (audibly) elements on the page for vision-impaired users. The ability for a screen reader to identify this item enables it to quickly jump to the heading, whereupon its contents will be read out to give an overview of the page, skipping over other content in the header (such as logos, navigation items, or social buttons).

More information: https://web.dev/headings-and-landmarks/

Applies to: Title Section

Text in the first block of your story Title Section, (along with being given the H1 tag) is automatically set as the Document Title. The title will appear as a label in the active browser tab of anyone reading the story, and used as a label if the story is bookmarked. The Document Title will also be used by screen reader technologies to announce the title of your story to visually impaired readers.

If you wish, it’s possible to set something other than the text in the H1 block of the story Title Section as the Document Title. You may for instance wish the document title to be more succinct or more descriptive than the text in your H1 tag, or you may need to add a title if for whatever reason, the H1 tag has been omitted from your story.

To modify or add a Document Title, click the SETTINGS tab at the top left of the editor, and then enter a descriptive title into the ‘Title’ field.

Applies to: Text Section, Scrollmation Section, Background Scrollmation Section

Header tags (H1, H2, H3, H4 & H5) are used by screen readers to quickly navigate a page. As such, they should be nested sequentially in your story. This means that your main subheadings should all be created with H2 tags, and then smaller headings within the same section, should be created with H3 tags, and so on...

Below is an example of properly nested HTML.

<h1>This is the Title of my Story</h1>

<h2>This is a subheading</h2>

<p>This is the body text for my article.</p>

<h2>This is another subheading</h2>

<p>This is the body text for my article.</p>

<h3>This is a smaller heading.</h3>

<p>This is the body text for my article.</p>

It would be incorrect to use an H2 tag within a section that has used an H3 tag for its heading. The heading numbers must decrease in sequence. It would also be incorrect to use an H4 tag directly beneath an H2 tag, as this would mean that you have skipped the H3 element.

To change the tag/element type of any block of text hover your mouse over that block and then select an element type from the panel in the top-left corner. This tag will usually default to ‘P’ (which stands for ‘paragraph’), but you can immediately update this element by clicking on any of the other H options.
​
​

More information: https://web.dev/heading-order/

Applies to: Title Section, Text Section, Scrollmation Section, Background Scrollmation Section, Text-on-Reveal Section, Text Over Media Section

The contrast between background colours and text colours will determine the readability of your story. WCAG guidelines state that this contrast ratio should be at least 4.5:1 for regularly sized text, and at least 3:1 for larger text (such as headings).

To determine the colour contrast ratio of a story, you can enter the hex codes for the foreground and background colours (as hexadecimal or RGB values) into the Colour Contrast Checker here.

Bear in mind that this calculation may become more complicated when a photograph or a video is the background element, as contrast between background and foreground will vary at various parts of the image or video.

The Shorthand editor provides Section Options that easily enable switching between different theme colours for sections, usually with a ‘LIGHT’ and a ‘DARK’ option. If the theme colours do not provide enough contrast alone, then the Overlay slider can be used to add a tinted layer between the foreground and background, and can be increased in opacity until the foreground text becomes legible.

​

To further increase the visual colour contrast between the most similar shades in the background and foreground, it is possible to select different text colours than those applied by changing between dark and light themes. Colours already available in your story theme can be found by clicking the paintbrush icon in the Section Options panel.

In most Shorthand plans it is also possible to add new colours to this set. A useful method for picking colours with a high enough contrast ratio might be to use the Colour Contrast Determinator identified above along with the FireFox eyedropper tool or colour selector in your image application. Select the colour in your background with the lowest contrast ratio to your foreground text, then use the Colour Contrast Determinator to select a new text colour with sufficient contrast to the background.

To use the FireFox colour picker tool, open a preview of your story in the FireFox browser and then go to the options panel. Choose ‘Web Developer’ and select ‘Eyedropper’. A circle showing a magnified ares of the page will appear, and identify the HEX colour code of the item within.

Applies to: HTML Sections, Inline HTML Blocks, ‘Rich Embeds’ in other sections

There are multiple ways to embed third-party content into a Shorthand story. The easiest is through the “Rich Embed” upload tool, which supports adding many different types of content simply by pasting in a URL.

In the majority of cases, this will result in code that is properly formatted.

An alternative way to add third-party content is by directly adding code into a HTML section or HTML block (available in some Shorthand . The addition of any custom code can introduce accessibility concerns. To ensure that issues do not affect the readability of your story, we would recommend that you consult the documentation of any widget that you embed, and that you enable any accessibility settings where applicable.

A common issue which can be easily resolved in your code is a missing ‘title’ attribute on an embedded iframe.

These title attributes are used by screen readers to describe the contents of the frame to their users. As such, these titles should be unique, descriptive, and present on every <frame> or <iframe> element.

Say, for example, that you were to add this iframe to your Shorthand story:
​
<iframe src="https://www.footballstats.com/"></iframe>
​
​

This is an iframe which has a ‘src’ (or ‘source’) value of ‘footballstats.com’. From the title of this website, one could assume that the embedded content will be a list of statistics for football games.

To ensure that any screen readers understand this, you will also need to add a ‘title’ attribute to the iframe element. You can do so by adding ‘title=”Descriptive Title”’ to the line as so:

<iframe title=”Football Stats” src="https://www.footballstats.com/"></iframe>

Another possibility is that an included iframe has a poorly descriptive title or a title identical to another iframe elsewhere on the page. On these occasions, you should replace the value of this title with something that is unique to this instance of the embed, and which adequately describes the content of the iframe.

More information: https://web.dev/frame-title/

Applies to: Uploaded images in Scrollmation Sections, Inline Images in any body text

When a screen reader reaches an image, it will check for the ‘alt text’ on that element. By default, Shorthand stories will have empty alt attributes on all image elements. The empty attribute prevents screen readers from their default behaviour, which is to read out the entire URL string for those images.

As this alt attribute will always be available, your Shorthand story will not report any accessibility error for missing alt text on images.

However, if your image contains context or data which is important to the understanding of the article (i.e. if the image is not merely decorative), then it should have alt text which adequately describes its contents, so that the description can be read.

This is in addition to the caption, which should be supplementary information about the image. The alt text should be adequate as a replacement to the image itself, as it is supposed to describe image content to users who cannot see it themselves.

Use descriptive text that conveys information about the link destination, either from the link text alone or from the link text along with its direct context.

Following are some good examples from this World Wide Web Consortium page on Link Purpose:

​

There are a number of places a Shorthand story can support playable media content (audio and/or video), and this type of content requires additional accessibility considerations.

Applies to: Media Sections, all Foreground Media, embedded Third-Party video players (in HTML Sections & HTML Blocks)

WCAG standards on time-based media (i.e. media which must be ‘played’) mandate that there should be legible captions for all speech, and for any pertinent sound effect.

The simplest way to ensure that this requirement is met is to use a YouTube video. This is due to YouTube’s option to automatically generate captions for videos that have been uploaded to that platform. After they have been generated, these captions can then be manually amended if there are any mistakes, or supplemented if there is any missing information or context.

If you are instead uploading a video directly to the Shorthand platform, then you will need to hardcode your captions directly into the video in order to meet this particular accessibility requirement. There are currently no means of adding captions to your uploaded videos from within the Shorthand editor.

Finally, if you are using an HTML Section, or HTML Block, to embed a third-party video widget, then you can manually provide captions by referencing a WebVTT file in that code snippet. These files are strings of text which are programmed to appear at specific timestamps in the video, and will remain for user-defined durations of time.

More information: https://web.dev/media-accessibility/

Applies to: Media Sections, all Foreground Media

As some users are unable to consume temporal content of any kind (captioned or otherwise), there is also a WCAG requirement to provide a full transcript of this content, alongside the media itself.

This transcript should contain all dialogue, as well as a description of any other pertinent, visual information. We would recommend that such a transcript be included as raw text beneath the media that it accompanies (so that it can be read out by a screen reader). However, you may instead choose to include it as an optional download (perhaps as a PDF or text file), by attaching the file linked to a Shorthand button, beneath or beside the video clip.

More information: https://www.w3.org/WAI/WCAG21/quickref/?versions=2.0#time-based-media

Many WCAG requirements are met by default when a story is rendered by the Shorthand platform. Shorthand is developed with consideration to keyboard-only navigation, issues with visual impairment, and an aria-compatible HTML structure.

The most notable aspects of accessibility functionality have been listed and explained in more detail below. We have also provided information as to how screen reader technologies will parse some of the differently structured Shorthand section types, such as Scrollmation, 2-Column Text, or Text-On-Reveal.

Applies to: All Sections (incl. Media Gallery)

As well as via scroll wheel or any standard mouse interaction, Shorthand stories can be scrolled through, from top to bottom, with the up and down directional keys on any standard keyboard.

In addition, every interactive element on the page can be ‘tabbed into’. This functionality means that Shorthand stories can be navigated, in their entirety, without need for a mouse. Hitting the tab button will enable focus on any clickable element, and then hitting the enter key will open or interact with that element.

This keyboard-only navigation also applies to the Media Gallery Section, which allows the user to tab through all available media, and then open the gallery into ‘lightbox’ mode focusing on a single item (starting with that item) by pressing enter. Once the gallery is open, the user can then tab through the available navigation buttons, as well as any media playing options, and select any of them by pressing enter again. The gallery can be closed by tabbing into and selecting the X button, or by pressing the escape key, from any point in the Lightbox.

More information: https://web.dev/keyboard-access/

Applies to: All uploaded images

If an image has been added inline, or into a Scrollmation section, but it is purely decorative (as opposed to containing any crucial or pertinent information), then it will be automatically ignored by all screen reader technologies. This is because Shorthand will always add an empty alt attribute to any image that is present in your article. I.e. Even if you choose not to add any alt text to your image through the Shorthand editor, there will still be an (empty) alt attribute on the rendered image element.

When a screen reader reaches an image with an empty alt attribute, it will skip over it. This is important because, if the alt attribute were omitted entirely, then the screen reader would instead read out the source URL of that image. This can be frustrating for visually-impaired readers, as these URLs can sometimes contain long strings of useless, random characters.

Whilst this automatic alt tag functionality will ensure that your Shorthand stories do not throw an ‘Images must have an alt attribute’ accessibility error, we would urge you to still think carefully about whether any of your images would be better if they did contain descriptive, alt text.

Wherever you add an image to convey information to your reader, you should also add descriptive alt text to convey that same information to visually-impaired readers.

More information: https://web.dev/image-alt/

Applies to: Reveal Section (with added text), Scrollmation Section, Background Scrollmation Section, 2-column Text Section

The content of a Shorthand story will generally be read through sequentially, by screen reader technology.

If a Text Section has been formatted into 2 columns, then screen readers will read out the entire content of the first column (the left column) and then read out the content of the second. If there are any instances of inline media (or embedded HTML content), then this content will be read out by the screen reader in the order that it appears in the text.

If the content is an image, then the alt tag for that image will be read out first, followed by its caption. If the content is playable media (such as a video or audio clip), then the screen reader will first recognise it as such, then read out the aria-label on its buttons (to give the user the chance to interact with that content), and then it will read out its caption.

When the screen reader reaches a Media Gallery Section, it will first read the aria-label for each button (which is “Click to enlarge”), then its alt text, and finally its Caption. If the user chooses to open the Media Gallery, from any of these images, then the screen reader will first read out the order number of that image, and then navigational options from that point.

NOTE: The user will then need to re-enable ‘read’, on their screen reader, to read out the alt text and captions for the Media Gallery content that is on display. They can then exit the Gallery by selecting and clicking the X, or by hitting the escape key. Once they have done so, they will need to re-enable ‘read’ once more to continue reading through the Shorthand article.

The only Shorthand section type where a screen reader may not read all of its content sequentially is the Scrollmation Section. In this section type, all of the content in the main text body will be read sequentially and any inline media will be read out as it is reached, but in the other column that contains the Scrollmation image frames that change as you scroll, the alt text and captions will be read out at the end of the section rather than when they appear on screen.

If these images need to be read out at specific points in the text, then we would recommend using the Insert Scrollmation Inline functionality. Doing so will place the image within the text when read on narrow screens or by screen readers, and ensure that the alt text and caption for each of those images will be read out at the appropriate point in the text.

Applies to: background videos, foreground animations, Scrollpoint sections

As some readers can get motion sickness from certain types of motion and animations, we have programmed some Shorthand story features to be automatically disabled when the reader's device has the "Prefers-Reduced-Motion" accessibility setting activated.

Commonly used as decorative full screen videos in Title and Text Over Media sections with optional foreground text, background videos in Shorthand will default to autoplaying on loop with no controls, and any sound will be muted.

If the reader's prefers-reduced-motion setting is on, background videos will not autoplay and will not have a means to play the video by default, however, story editors have the option of adding a play/pause button to background videos to give readers more control over playback.

This feature can be toggled on from the 'SETTINGS' tab in the story editor, as shown below:

If added, a play/pause button will be overlayed over each background video in a story, and readers can click any of these pause buttons in order to stop all instances of background videos playing. If background video playing in the story has been paused, clicking any of the background video play buttons will enable all background videos to play automatically again when in view.

When the reader's prefers-reduced-motion setting is off, the videos will still autoplay by default but can be paused, while if prefers-reduced-motion is on then the videos will start paused and the reader will be able to play the video if they wish.

Shorthand's foreground animation feature allows story editors to set images in the foreground of your story to fade, rotate, and/or zoom into view when your readers scroll, without the need for code, video, or animated gifs.

These animations will automatically be disabled if the reader's device has the prefers-reduced-motion setting turned on.

Shorthand's Scrollpoint section feature allows story editors to highlight different parts/points of large images, and as the reader scrolls through the image, the screen will scroll and possibly zoom to transition between each highlighted point.

If the reader's device has the prefers-reduced-motion setting turned on, the transitions between each will occur instantaneously with no animation.

Applies to: All Text Blocks

Most web fonts are displayed as LTR (Left-To-Right), by default. However there are some fonts, including those for the display of Arabic or Chinese text, which will need to display in RTL (Right-To-Left) instead.

For users that require these RTL fonts in their Shorthand articles, a custom theme can be programmed to default to this layout. On request, any number of additional fonts can be added to the custom theme and can be individually set as either LTR or RTL.

More information: https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/RTL_Guidelines

Applies to: Previewed & Published stories on mobile devices

Pinch-to-zoom is the ubiquitous technology which allows mobile users to decrease or increase the size of their web content by placing two fingers on the screen and then moving them toward or away from one another.

To assist partially-sighted readers, or those with otherwise impaired vision, Shorthand stories have enabled this ‘pinch-to-zoom’ functionality on mobile devices (phones and tablets) in both portrait and landscape mode.

More information: https://web.dev/responsive-web-design-basics/

Applies to: Navigation bar/Story Header

Aria tagging is the process of applying attributes to HTML elements which are then read out by screen reader technologies. Some of these tags include ‘aria-hidden’, which is used if an item is decorative and should be ignored by the reader, and ‘role’ which describes the function of that element (e.g. ‘button’).

For accessible navigation, the ‘hamburger’ navigation buttons (a button shown as three vertically stacked horizontal lines) in mobile Shorthand stories will be tagged with the aria-controls=navigation attribute. The desktop navigation will also be identifiable with the ‘navigation’ value of its aria role. Other interactive elements throughout the story will also be appropriately aria-tagged to ensure full usability through screen reader technologies.

More information: http://web-accessibility.carnegiemuseums.org/code/navigation/

Applies to: Inline Media, Scrollmation Images, Background Scrollmation Images

Many of the image assets in a Shorthand story utilise a “lazy-loading” method to prioritise the loading of items early in a story. This means that there will be assets on the page which are not loaded until the user has reached that point of the story, or which may load after a slight delay (such as high quality versions of the story images).

In these cases, the additional elements have been wrapped in an ‘aria-hidden’ attribute, which will prevent screen readers from reading out the contents of those blocks. This will ensure that only pertinent information is transmitted to partially-sighted users while decorative, lazy-loaded, or placeholder content will be automatically ignored.

More information: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-hidden_attribute

Applies to: All sections

Most modern browsers include the ability to zoom into the content of a page. Rather than actually zooming into the screen, this zoom functionality generally works by increasing the size of the individual elements on the page (such as font size). As such, this is a commonly used accessibility feature for partially-sighted users and allows them to increase the size of any images or text content.

Shorthand stories have been designed so that the font size can be increased by up to 400%, without that text being cut off at the end of any section. This functionality is enabled regardless of which section type has been used.

More information: https://www.w3.org/WAI/WCAG21/Understanding/reflow.html

There are numerous tools available for testing your Shorthand story against the main WCAG accessibility criteria.

Please bear in mind that these tools cannot test every aspect of accessibility on a page. This is particularly true of interactive elements, such as the ability to navigate through your story without using a mouse. In these instances, you will need to manually test your stories.

However, for testing against a number of other accessibility criteria, the tools that we’ve listed below can be very helpful and efficient.

The Google Chrome web browser has built-in functionality which allows you to determine an ‘accessibility score’ for your story. To use Lighthouse, you’ll need to first open the Chrome Developer Tools.

On a Mac, the keyboard command for opening these tools is Option + Command + J.

On a Windows machine, the keyboard command is just f12.

Once the tools are open, click on the two arrows in the bar at the top, and then select the ‘Lighthouse’ option.

​

From here, you will need to uncheck every category box except for ‘Accessibility’, and then click Generate Report. You will be given the opportunity to generate a report for either Desktop or for Mobile. We would strongly recommend that you generate both of these reports to ensure that accessibility standards are being met across every platform.

If you are using either of the Google Chrome or Mozilla Firefox web browsers, then you can download a tool which will allow you to quickly check the accessibility status of any webpage.

To download the Wave Evaluation extension, please click here.

Once this tool has been installed, you can click the Wave Icon to the right of your browser URL bar to enable the application on any page. Doing so will allow you to read through the details of any accessibility concerns. You can then click on any of these issues to scroll to the point of your webpage that has caused the error. The details of the error should provide enough information to resolve each concern.

More information: https://wave.webaim.org/

A useful method for testing the accessibility of a Shorthand story is to open the page whilst using screen reader technology. Screen readers will use hidden attributes throughout the page to jump between blocks and media elements so that partially-sighted users can easily consume that content.

Two of the most commonly used and widely available screen reader technologies are Voiceover and Narrator, which are built into Mac and Windows machines respectively.

Another popular and free screen reader for Windows is NVDA.

To test the accessibility of your Shorthand story with a screen reader you will need to enable the applicable technology and then navigate a browser to one of your stories in preview mode (or an already published story).

This test can be considered successful if all of the pertinent information (including alt attributes on any accompanying image) is read out in the correct sequence.

More information: https://www.apple.com/voiceover/info/guide/_1121.html

https://support.microsoft.com/en-us/windows/complete-guide-to-narrator-e4397a0d-ef4f-b386-d8ae-c172f109bdb1

The information above is primarily practical for applying accessibility standards to your Shorthand stories. For a more in-depth and comprehensive look at accessibility on the Shorthand platform, please also read through our blog post on The Craft.