accessibility: Difference between revisions

From IndieWeb
(Fleshing out Writing section with relevant examples from See More)
Line 116: Line 116:


== Video & Audio Content ==
== Video & Audio Content ==
Much like with images, video and audio content can be made accessible to many more people by providing a text alternative.
<blockquote>Podcasts, are, by nature, designed for the blind and the visually impaired because they are audio experiences.</blockquote>
{{citation
| title = Make sure your podcast website is as accessible as your content
| url = https://blindjournalist.wordpress.com/2019/03/18/make-sure-your-podcast-website-is-as-accessible-as-your-content/
| author = [https://blindjournalist.wordpress.com Robert W Kingett]
| published = 2018-03
| archiveurl = https://web.archive.org/web/20190622115813/https://medium.com/@blindwriter/make-sure-your-podcast-website-is-as-accessible-as-your-content-c8791a6c80f2
}}
=== Closed Captions ===
Video content should be captioned, particularly for speech. Text can be overlaid to appear as the video plays, preferably so that the words on-screen mirror what someone can hear.
Some tools will bake captions directly into the video file, either by saving them onto the frames themselves, or by providing the necessary metadata for video players to dynamically render the text as an overlay on top of the video. The latter is generally considered better, as it allows users to alter font and colour, as well as providing assistive technology and localisation tools with an effective transcript that can be translated into whatever the user needs.
Apart from speech, it is often useful to caption important sound effects, the emotionality of music (e.g. "sad music begins playing"), or even the absence of sound entirely ("[silence]"), so that context is not lost.
Captions allow the hard-of-hearing and deaf users to access otherwise meaningless content, but they also benefit people watching videos in noisy environments – such as during a commute – or if they lack sounds for other reasons, e.g. a broken speaker.
=== Transcripts ===
For purely audio-based content, such as podcasts, providing a text transcript is necessary to allow access to deaf and hard-of-hearing users.
Transcripts should contain all spoken language within an audio clip, as well as any additional context like sound effects and who is currently talking. Providing timestamps can be beneficial, depending on how the audio is being used.
As mentioned above, well-formatted closed captions can often double up as transcripts, particularly if timestamps are included. However, it is still beneficial to provide a transcript in text format (rather than purely as captions on a video), so that users can effectively read through a video. This has been shown to help people who retain visual sources better than auditory ones, and can significantly help people with various learning disabilities. On sites like YouTube, this can be achieved by adding a transcript to the description beneath a video.
It can also be beneficial for video content to provide descriptive transcripts, preferably within the speech transcript. These include key details about what's happening on-screen, in the same way that descriptive text works with images. For example:
<blockquote>
<p>[00:00] Description: The keynote speaker, Steve Jobs, walks onto a stage looking confident, wearing their trademark black turtleneck and jeans. A slide appears that reads "Introducing". Steve smiles.</p>
<p>[00:10] "[Steve] Welcome to this year's event!"</p>
<p>[00:25] "We've got some exciting news for you today."</p>
</blockquote>
See also: [[transcript]]


== Animations & Sound Design ==
== Animations & Sound Design ==

Revision as of 18:16, 7 March 2022

This article is a stub. You can help the IndieWeb wiki by expanding it.


Accessibility is the practice of designing so that people with disabilities can have equal access to information and functionality, applicable to both websites as well as physical environments.

In keeping with the IndieWeb principles that "UX and design is more important than protocols, formats, data models, schema etc.", it's important to make sure that one's site is inclusively "human readable" by as many people as possible.

While designers may create for themselves in pristine and ideal environments, readers using other devices/hardware in harsher environments or who may have various visual, auditory, or other deficits may not be able to access their content easily or at all.

Considerations

Accessibility is focused on removing barriers to enable broad access to tools, information, and community. With that in mind, it's worth remembering to consider the following, regardless of whether you are working in physical or digital spaces:

  • Visual: People with blindness or low vision may rely on alternative senses, most commonly auditory and/or touch, to access information and navigate the world; colour-blindness and various other vision impairments mean that colour and contrast must be considered carefully.
  • Auditory/Hearing: People who are deaf or hard of hearing may need alternative methods to access audio or verbal information, and may miss purely audio-related cues or alerts.
  • Motor Control: Many people are unable to use specific input methods. Some people lack the fine motor control needed to use computer mice, whilst others may be able to use them but only slowly. Others struggle with the precision of touch inputs, particularly on smaller mobile interfaces. Consider response times and support a variety of input methods.
  • Cognitive Disabilities: Mental illnesses and cognitive conditions can be triggered by certain stimuli, such as animations or loud noises. Appropriate warnings and overrides should be provided as necessary.
  • Neurodiversity: A large percentage of the population live with some form of learning disability or neurodivergence, which can cause distractibility, inability to remember, or make it harder to focus on large amounts of information.

IndieWeb Examples

Interface Design

Formatting

Links

Color and Contrast

Kevin Marks has written an interesting article on How the Web Became Unreadable which discusses some interesting accessibility issues that lead to many users having difficulty seeing material on websites.

The article includes some interesting examples and tools which may help others:

When making the contrast of text and other visual elements lower, designers need to consider the experience of the following:

  • elderly users or those with bad vision
  • low quality monitors
  • bad lighting and glare
  • reading on tiny screens
  • ...


Writing

Text can be a tricky balancing act. Whilst most assistive technologies deal with text well, the content is naturally quite personal. Everything from local linguistic quirks to how text is formatted can be important for authorial intent and honesty, but it can also make it harder to access for certain people.

It is best to be most considerate when writing for a broad audience – for example, with technical documentation or introductory guides.

Language

There are many ways to increase how easy a section of text is to read. Simplifying the language you use by replacing or explaining technical words or niche phrasing helps a lot for people with various cognitive disabilities. It also makes content more accessible to non-native speakers.

Shortening sentences often helps those with learning disabilities, like dyslexia. That can also benefit people with ADHD or other neurodivergences who can be easily distracted or lose focus.

Plain Text

Plain text (or plain language) is a style of writing designed to reduce barriers to information and content. It uses an everyday vocabulary, short sentences, and a simplified grammatical structure to ensure text is as easy to understand as possible, to the widest audience.

You can see a full example of an article translated into plain text here: What makes writing more readable?

Excerpt from the above before translation:

The benefits of plain language aren’t limited to universally challenging texts like legal documents and tax forms. Even everyday writing, like news articles, can still pose a barrier for some readers.

And the same passage translated to plain text:

Some kinds of writing are hard for everyone to read, like tax forms. But everyday writing, like the news, can be hard to read too.

Font Choice

In general, sans-serif fonts tend to be easier to read:

"It has been found that sans-serif fonts improve readability for people with reading/learning difficulties like Dyslexia http://dyslexiahelp.umich.edu/sites/default/files/good_fonts_for_dyslexia_study.pdf @mmatuzo" @LeonieWatson October 9, 2019 source

There are also "hyper legible" fonts specifically designed to help low vision readers, such as Atkinson Hyperlegible, which is freely available for use from the Braille Institute. Some research has suggested that these may also have benefits for people with dyslexia, though more study is needed.

Line Length

People will often struggle to read particularly long or wide lines of text. In general, somewhere between 60 and 75 characters is considered the upper limit, but smaller can be better for those with certain learning disabilities.

In CSS, line length can be limited using font-relative units such as ch, rem, or em. A common pattern is to set the main content of an article to around 60ch: Limit line length to increase readability

Further Reading

Images

Text Descriptions

Images are inherently visual content, so providing text-based descriptions can be extremely useful.

On websites, this "alternative text" (frequently referred to as "alt text" and provided in HTML via the alt property) can then be used by assistive technologies such as screenreaders, converting an image into an audio description or a braille readout.

Usefully, browsers will also expose the alt text if an image fails to load, providing a graceful fallback even for sighted users.

In printed media, descriptions are most often presented as captions, typically to one side or beneath an image.

For more specific best practices, further reading, and IndieWeb examples, see: alt text

Video & Audio Content

Much like with images, video and audio content can be made accessible to many more people by providing a text alternative.

Podcasts, are, by nature, designed for the blind and the visually impaired because they are audio experiences.

2018-03 Robert W Kingett: Make sure your podcast website is as accessible as your content (archived)

Closed Captions

Video content should be captioned, particularly for speech. Text can be overlaid to appear as the video plays, preferably so that the words on-screen mirror what someone can hear.

Some tools will bake captions directly into the video file, either by saving them onto the frames themselves, or by providing the necessary metadata for video players to dynamically render the text as an overlay on top of the video. The latter is generally considered better, as it allows users to alter font and colour, as well as providing assistive technology and localisation tools with an effective transcript that can be translated into whatever the user needs.

Apart from speech, it is often useful to caption important sound effects, the emotionality of music (e.g. "sad music begins playing"), or even the absence of sound entirely ("[silence]"), so that context is not lost.

Captions allow the hard-of-hearing and deaf users to access otherwise meaningless content, but they also benefit people watching videos in noisy environments – such as during a commute – or if they lack sounds for other reasons, e.g. a broken speaker.

Transcripts

For purely audio-based content, such as podcasts, providing a text transcript is necessary to allow access to deaf and hard-of-hearing users.

Transcripts should contain all spoken language within an audio clip, as well as any additional context like sound effects and who is currently talking. Providing timestamps can be beneficial, depending on how the audio is being used.

As mentioned above, well-formatted closed captions can often double up as transcripts, particularly if timestamps are included. However, it is still beneficial to provide a transcript in text format (rather than purely as captions on a video), so that users can effectively read through a video. This has been shown to help people who retain visual sources better than auditory ones, and can significantly help people with various learning disabilities. On sites like YouTube, this can be achieved by adding a transcript to the description beneath a video.

It can also be beneficial for video content to provide descriptive transcripts, preferably within the speech transcript. These include key details about what's happening on-screen, in the same way that descriptive text works with images. For example:

[00:00] Description: The keynote speaker, Steve Jobs, walks onto a stage looking confident, wearing their trademark black turtleneck and jeans. A slide appears that reads "Introducing". Steve smiles.

[00:10] "[Steve] Welcome to this year's event!"

[00:25] "We've got some exciting news for you today."

See also: transcript

Animations & Sound Design

Physical Environments

This section is a stub. You can help the IndieWebCamp wiki by expanding it.

Remember those with disabilities when setting up event spaces.

  • This is something that came to mind while planning IWC Bellingham and some of the event space is not wheelchair accessible. I'm researching and considering how to best advertise that clearly to potential attendees. gRegor Morrill

Event accessibility statement examples:

  • Beyond Tellerand Terms of Service: Accessibility heading

    Please contact us, if you want to attend at workshops or the conference and have any special requirements such as access for wheelchairs. We will do our very best to accommodate you.

More reading:

Resources

Below is a list of useful resources to turn to when considering web accessibility:

To Do

Several IndieWebCamps and even HWC meetings have included material and discussions on accessibility that could be transplanted onto this page.

See Also

Retrieved from "https://indieweb.org/wiki/index.php?title=accessibility&oldid=80009"