accessibility: Difference between revisions

Revision as of 01:32, 17 December 2019

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.

Visual

Remember to consider people with blindness, low vision, and color-blindness.

Color and Contrast

Kevin Marks has written an interesting article on How the Web Became Unreadable which discusses some interesting accessibility issues which covers even average users having difficulty seeing material on websites.

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

Color and Contrast chart
Lea Verou's Contrast Ratio tool
Color Contrast Checker
Contrast Rebellion gives some great motivation why contrast is important
...

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
...

Auditory / Hearing

Remember those who are hard-of-hearing or deaf.

Motor Control

Remember those with the inability to use a mouse, slow response time, limited fine motor control or even those with "fat fingers" using small mobile interfaces.

Cognitive defecits

Remember those with earning disabilities, distractibility, inability to remember or focus on large amounts of information.

Dyslexia

Some research indicates that custom fonts can be of help those who suffer from reading issues that include dyslexia.

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.
- Beyond Tellerand Accessibility:
  On this page you can find the accessibility information for the venues and this website.

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.

WCAG
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!
- 2018-01-10 Eric Meyer: Increasing Accessibility (archived) where 2 days later, Eric shows he has acted on the advice.
A List Apart On Alt Text, great discussion of cases in the comments.
Accessibility and Contrast Bookmarklet
Userway.org helpful accessibility plugins that work without refactoring your website's existing code and will increase compliance with WCAG 2.0, ATAG 2.0, ADA, & Section 508 requirements.
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
Scott Jehl shares some simple CSS to disable animations for visitors that do not want those
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://blindjournalist.wordpress.com/2019/03/18/make-sure-your-podcast-website-is-as-accessible-as-your-content/
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
default to sans serif: https://twitter.com/leoniewatson/status/1181968960746594307
- "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
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

@@ Line 113: / Line 113: @@
 * 2019-11-05 [https://nolanlawson.com/2019/11/05/what-ive-learned-about-accessibility-in-spas/ What I’ve learned about accessibility in SPAs] <-- useful for IndieWeb development of accessible UIs, [[reader]]s, perhaps sites!
 * https://marcozehe.de/2019/12/16/call-to-action-html-needs-more-native-rich-widgets/
+* [https://daverupert.com/2019/12/why-details-is-not-an-accordion/ Why <details> is Not an Accordion]