accessibility

From IndieWeb
(Redirected from a11y)

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


Accessibility is key to designing web sites in an inclusive manner, lowering barriers to information, interaction, and communication, to make the web accessible to people with disabilities, and sometimes a literal site path (/accessibility) for a website accessibility statement; the IndieWeb community encourages both accessible events & personal sites.

Event accessibility statements are also helpful for all events, whether in-person, hybrid, or virtual.

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, ideally to also participate equally.

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 color 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 distractability, inability to remember, or make it harder to focus on large amounts of information.

IndieWeb Examples

See accessibility statement examples.

Does your site implement accessibility features? Add yourself and what features you’ve implemented!

Design

Formatting

Links

Color and Contrast

Designers should consider the following experiences when deciding on the contrast of text and other visual elements:

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

Why:

Tools:

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.

See Also:

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

Animations can be triggering for certain cognitive disorders, leaving people feeling ill, dizzy, or even in pain. They are also distracting, meaning that people with ADHD or other disorders who may easily lose focus or attention can struggle to ignore them. Particularly quick or strobing motion may even trigger seizures.

Similarly, sound design (sound effects or background music) can cause people to lose their train of thought, struggle to focus on text or imagery in front of them, or – if particularly loud and sudden – be a trigger for PTSD and other mental illnesses. When poorly implemented, sound effects can also leave people confused or unsure of what has happened, resulting in anxiety and stress.

As a result, the general rule of thumb is to use animations and sound design sparingly and only where its purpose is clear. For example, having a button make a reassuring "click" when pressed provides meaningful auditory feedback and may even improve the accessibility of a user interface.

That said, it is always best to provide people with clear options to disable animations and mute sound effects. Where possible, using predefined settings, such as OS-level preferences, is also considered a good practice.

Further Reading

Physical Environments

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

See: accessibility statement Event Examples

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

Accessibility Overlays

In recent years a number of companies have released (normally paid-for) accessibility "plugins" that claim to be able to make websites accessible and/or meet specific WCAG or ADA compliance levels.

These services can be added to a website in a similar way to consent forms or chatbots. Most commonly, this means loading a third-party JavaScript file that then attempts to "fix" accessibility concerns by altering the web page before it is fully rendered in the browser. Some also provide a floating GUI "toolbox" that allows users to take accessibility-related actions, such as modifying the font size or UI colours. Examples include AccessiBe, UserWay, and EqualWeb.

Criticisms

Accessibility overlays are typically marketed as "one-click installs" or "quick fixes" that can solve all accessibility concerns. However, in practice, they have routinely been found to _decrease_ the accessibility of a given site or page, and the companies behind them are frequently caught up in controversies.

Common concerns include:

  • An over-reliance on JavaScript, particularly in ways that often conflict with assistive technologies like screen readers. Even where conflicts are well managed, client-side JavaScript can fail for other reasons, resulting in extremely broken user experiences (see js;dr).
  • Being too focused on legal compliance, rather than actual user needs.
  • Marketing one-size-fits-all solutions that result in frequent edge cases that break or degrade user experiences, particularly for people using assistive technology.

As a result, in May 2021 a large number of key accessibility specialists, experts, and disability rights activists signed an open letter discouraging the use of accessibility overlays: The Overlay Factsheet.

Additional Information

Resources

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

Sessions

IndieWebCamp sessions about or related to accessibility:

To Do

  • simplify and reduce this page to IndieWeb-specific relevant content, and link to broader web accessibility and accessible design resources (e.g. https://developer.mozilla.org/en-US/docs/Web/Accessibility ) instead of duplicating it here where it won't necessarily be maintained as well.
  • add more sessions. Several IndieWebCamps and even HWC meetings have included material and discussions on accessibility that should be incorporated onto this page.

See Also

  • WCAG
  • accessibility statement
  • https://www.nngroup.com/articles/
  • https://inclusive-components.design/
  • https://24ways.org/2017/wcag-for-people-who-havent-read-them/
  • 2018-01-08 Eric Meyer: How Do I Increase Accessibility? (archived) in which the community is asked for general advice surrounding accessible blog mark-up, and provides in the comments!
  • Accessibility and Contrast Bookmarklet
  • There is software to simulate colour blindness that will help in picking palettes where colour differences are a required design element (e.g. in graphs). For macOS the free and open-source Sim Daltonism is very easy to use.
  • https://tenon.io - helpful checking tool
  • http://pa11y.org/ - accessibility checking tool
  • https://www.funkify.org/ - Fantastic accessibility checker & simulator
  • Smashing TV: Léonie Watson on why semantic HTML document landmarks assist her using a screenreader - 5 min intro on how screenreaders present pages
  • Ethan Marcotte on The Web We Broke
  • https://clrs.cc/a11y/
  • https://2019.code4lib.org/general-info/accessibility
  • https://www.scottohara.me/note/2019/05/07/resources.html
  • 2019-07-30 Andi Galpern / Adobe Blog: Designing Accessible Experiences at Scale / Accessibility is no longer an afterthought. It’s a requirement and should be considered from the very start of your design process.
  • https://www.customerservant.com/in-reply-to-cambridgeport90-and-jgmac1106-regarding-the-indieweb-fifth-choice-the-elephant-in-the-room-of-other-cmss-and-accessibility/
    • "This reply is part of a conversation on this post which has carried over to Twitter. There’s an elephant in the room we need to talk about regarding the fifth choice of non-WordPress CMS, and it’s accessibility, (or lack thereof) of those content management systems.Before anything else, Greg, I’m not mad at you for picking the fifth choice. WordPress isn’t the only thing out there, and it shouldn’t be the only thing out there, if for no other reason than the principles governing the Indieweb basically state that there shouldn’t be one platform/CMS to rule them all. That said, there’s a reason a lot of people with disabilities, (screen reader users especially), choose WordPress, and to a lesser extent, Drupal.Aside from the things that popularity brings, (one-click installs, for example), the fact is that content management systems outside of WordPress and Drupal and somewhat Joomla! do not take accessibility into consideration as part of their development and design roadmaps. And nobody wants to be the first person to start advocating piecemeal with each and every one of these only to be told that “Accessibility is not a priority” or any of the other excuses put forth for why something isn’t accessible. Nobody certainly wants to do it for free.I continue to contribute to WordPress accessibility for a whole host of reasons, some of which have to do with self-interest. I use WordPress and I want to give back, and it makes sense for me to invest in the platform that has helped me make my living for the last ten years. I also want others in the blind community to have the opportunity to use WordPress to make a living of their own. In order for that to happen, accessibility has to be part of the project.And unfortunately, experience has taught me, (as well as others in the disability community), that accessibility just isn’t a high priority, especially if it gets in the way of some cool new feature. That’s true for everything from Cpanel to PHPMyAdmin all the way down the line to just about every other thing used to create websites.Granted, given the insistence in the indieweb space on semantic HTML, I could find that I am pleasantly surprised that Known, for example, works just fine. And there are good reasons for using it, most notably that indieweb stuff just seems to work out of the box. What I’m not sure about though is the accessibility of themes/templates, and whether or not post kinds display is accessible, to say nothing of the creation process.Which brings me back to WordPress and Drupal, but especially WordPress. People who use screen readers, and to a lesser extent other assistive technologies, use WordPress because work is constantly being done on accessibility, along with the reasons that draw others to it: One-click installs, lots of options, thriving design/development community to create those options, and (relative) ease of use. And because things like Squarespace, Wix, and pretty much every other open source/free software content management system has significant accessibility problems, plus learning curves and all that jazz.So, to get back to my contention that indieweb WordPress will have to embrace blocks, I completely get that none of us want to touch React, and believe me I haven’t developed some sudden love for Gutenberg. I just think that, if indieweb stuff is going to take off, it’s going to have to be easier to handle the theming aspect of indieweb, and I think the easiest way to do that is to go with the flow of the community as much as possible. I’m not suggesting that the work be apportioned to others. Far from it. I’m saying we collectively need to do this, not that someone else should do it. I just don’t see the current theme status quo sticking around for long, and right now, we’re forking default themes probably because they are the easiest to fork, Independent Publisher being the exception.I’d feel sorry for anyone who tried to fork a Theme Forest theme. That’s something I wouldn’t wish on my worst enemy. And Genesis, as much as I love it, is going to take some thinking through due to the changes they’re making, and the fact that generally plugins that work best with Genesis are built to work with that framework and the way it does things and not to be compatible with stuff outside of that. There are some exceptions, (Give, Gravity Forms, anything that uses shortcodes to insert its content). But I think getting something like Post Kinds working with Genesis, plus making sure that it still works with everything else, would be a ton of work. I think there would have to be a separate Genesis-specific plugin to handle post kinds for that framework. And I’m using Genesis as my example because it has 250,000 users, a thriving design community along with development community, and is really quick to set up sites with. Problem is, that community is embracing blocks, because admittedly blocks make some things a lot easier to do, homepages that aren’t just static but are a mix of static and dynamic, for example. Up until Gutenberg that’s been accomplished with widgets and sometimes custom loops. Blocks/Gutenberg eliminates a lot of that work.So the Genesis community isn’t going to want to go back to the old way, even if indieweb is important to some of the community members. Users aren’t going to switch from Genesis to what’s currently there for indieweb with regard to themes unless they decide to be idealistic above everything else, which means indieweb is adopted by less people overall. While Genesis is the example under discussion here, all of this applies to every other theme framework, and themes in general. In short, blocks is where it’s at, whether I like that or not, and even if I still hate React for all of the reasons I hate it." @Amanda Rush(Placeholder, edit later) WordPress powers over a quarter of the web. With such a large market share comes a shared responsibility to create a web that everyone can use and enjoy, regardless of how they access it. August 29, 2019
  • 2019-11-05 What I’ve learned about accessibility in SPAs <-- useful for IndieWeb development of accessible UIs, readers, perhaps sites!
  • https://marcozehe.de/2019/12/16/call-to-action-html-needs-more-native-rich-widgets/
  • Why <details> is Not an Accordion
  • CSS for marking something screen reader only including optional code for making it hidden but focusable
  • 2020-06-11 Olu Niyiawosusi *[*https://alistapart.com/article/building-the-woke-web/ Building the Woke Web: Web Accessibility, Inclusion & Social Justice]
  • [https://blog.datawrapper.de/beautifulcolors/ How to pick more beautiful colors for your data visualizations[
  • https://www.perkinselearning.org/technology/blog/how-do-people-vision-impairments-use-emoji
  • A website that's only accessible via screen reader
  • Show/Hide password accessibility and password hints tutorial
  • Form Design by Geri Reid, following Inclusive Design and WCAG principles
  • https://www.scottohara.me/blog/2016/10/15/is-it-accessible.html
  • simple, semantic HTML can get you a long way toward building an accessible experience. Not using the right semantic tags can cause problems : https://mobile.twitter.com/mmatuzo/status/1481370546176770049
    • "How many HTML elements do you need to create a checkbox?

      Exactly, 14! 14 is the right answer." @mmatuzo January 12, 2022
  • 2022-05-04 I've analyzed the accessibility of over 1600 personal sites — includes sites from IndieWeb web ring!
  • Tools to help the colorblind (protanopia) for choosing color pallettes https://mathstodon.xyz/@christianp/111759646072194260
    • "I'm severely colourblind - my eyes can hardly detect red light at all.
      So, working in web development, picking colour schemes is hard.
      There are tools around to help you pick accessible colour schemes, but they assume that you can tell by looking that a colour is the one you want, and the only information you need the computer to calculate is the contrast ratio.
      I realised I need a tool that will take the name of a colour and find a shade that gives a target contrast ratio.Here it is: https://colourblind-palette-maker.glitch.me/It uses the new APCA perceptual contrast algorithm and the Oklab colour space to help me find colours that people with better colour vision will interpret correctly, while ensuring there's good contrast for as many people as possible.#accessibility #a11y #WebDev" @christianp January 15, 2024
  • 2024-07-04 Craig Hockenberry: Dynamic Type on the Web (archived) on how to make sure your website adapts to the text size chosen by iOS users
Retrieved from "https://indieweb.org/wiki/index.php?title=accessibility&oldid=96149"