esmi 12:14 pm on March 8, 2013
Tags: documention ( 4 ), theme ( 7 )

Accessibility for Theme Developers: First Draft Complete

I think I’ve finally finished! *gasp* Thank you to everyone who provided earlier feedback and jogged my memory.

Is there anything on the completed page I need to re-word or explain in more detail?

As previously, please post all feedback here rather than on the draft page itself.

#documention, #theme

Dane Morgan 4:21 pm on March 8, 2013

that content must:

needs a ‘be’. Also with a list that each part concludes a thought, no : is required, use periods at the end of each item title to tie them to the beginning clause.
mrwweb 4:46 pm on March 8, 2013

This is a really great resource! Thanks @esmi.

A few thoughts:

1. Maybe I’ve been doing this wrong forever, but it seems that the “good read more” code snippet could be simplified a bit:
<?php printf( __('%1$s – read more’, ‘theme_text_domain’), get_the_title() );?>
I also wonder if this technique deserves mention. It’s weird but I’m planning on using it in future themes I build.

2. There’s no mention of motion issues. Almost every slider I see these days has accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) issues including slides advancing too quickly, text embedded in images without alt text, no keyboard navigation, no play/pause button provided, etc.. I wonder if those issues, particularly speed/motion,deserve mention.

3. This could take people down a wormhole, but I wonder if citing appropriate WCAGWCAG WCAG is an acronym for Web Content Accessibility Guidelines. These guidelines are helping make sure the internet is accessible to all people no matter how they would need to access the internet (screen-reader, keyboard only, etc) https://www.w3.org/TR/WCAG21/. standards might add a bit of muscle to the points.
esmi 6:09 pm on March 8, 2013
it seems that the “good read more” code snippet could be simplified a bit

I added the extra variables so that developers could use the generated span to hide the first part of the link off screen – if that was preferred. Personally, I do think it reduces screen clutter by a fair amount whilst still supporting screen reader users.

There’s no mention of motion issues.

They’re under “Things To Avoid – Autoplay & Animations”.

I wonder if citing appropriate WCAGWCAG WCAG is an acronym for Web Content Accessibility Guidelines. These guidelines are helping make sure the internet is accessible to all people no matter how they would need to access the internet (screen-reader, keyboard only, etc) https://www.w3.org/TR/WCAG21/. standards

I’d rather not get down to the level of citing specific WCAG criteria in the main body of the page for a couple of reasons:
- I’m really wary of overwhelming those who are relatively new to web accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility). Better that they implement some of the points in the document than run screaming for the hills vowing never to look at it again. 😉
- I’d like to avoid leading people into a “checklist” mentality, if that’s possible. Ideally, we want developers to think first instead of making assumptions all of time, yes?
- Frankly, WCAG 2.0 is enough to scare anyone!
That said, I was wondering if I ought to include some more specific WCAG links in the General Resources section.
- mrwweb 11:49 pm on March 8, 2013
  
  Wow. Totally missed the autoplay & animations section. Not sure how. Sorry ’bout that.
  
  However, what this does make me think of is whether it might be worth adding a “common features with common accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) problems” sections that references the relevant sections. I wonder if a theme developer would blow past “link text” but latch on to “read more links.” Same think with slideshow sliders. Of course this list couldn’t be exhaustive, so it might be more trouble than it’s worth and could lead to your fear of checklisting themes for accessibility, which I share.
_Redd 6:29 pm on March 8, 2013

Do you think a warning against using tables as layout for forms (or other) should be mentioned?
Sharon Wachsler 1:05 am on March 9, 2013

Wow! What a great resource this is. It covers a lot of ground, and I like how you use a few very basic concepts at the beginning to encourage developers to think along those lines and then also give lots of specific examples later of the way they are implemented.

I also learned from this document. For example, I always spawn new tabs because I find that much easier for me when I use websites, but I didn’t know this causes a problem for people who use screen readers. (I’m not sure what to do about this. Maybe I will decrease my use of them a lot and then include a link to get back to the original post?)

I liked the example of the Japanese cartoon sending kids to the hospital. It makes it very concrete. I have noticed that slideshows on autoplay are more and more common. My independent living center has an autoplay slideshow on their website now! [head::desk]

A typo: “And do not play any sounds with the user’s express permission.” I think you mean “without” permission, yeah?

Thank you for all your hard work and the care that went into this.
andyvaughn 7:59 pm on March 12, 2013

HTML5 longdesc attribute: Since this can fall under our umbrella, should we add this to the “theme development” section?
(First public working draft today): http://www.w3.org/TR/html-longdesc/
esmi 8:17 pm on March 12, 2013

Nope. AT support for longdesc is very limited to non-existent. right now. I really wouldn’t bother using it — let alone ever relying upon it. Maybe re-visit it in a a few years to see if support has grown as HTML5 support increases?
- andyvaughn 8:30 pm on March 12, 2013
  
  Makes sense. Just wanted to cover all bases.
fingli 9:42 pm on March 12, 2013

May I suggest Total Validator http://www.w3.org/2001/sw/wiki/TotalValidator as another useful tool for checking accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility). From my experience with it I can say it makes correct checks (no false positive warnings) and they updated it regularly.
esmi 1:15 pm on March 13, 2013

Oh – yes! I’d forgotten that one. I recently tried it out on a large site audit and was pleasantly surprised just how well it performed. I’ll add it to our list of useful tools.
Rian Rietveld 2:46 pm on March 18, 2013

Hi @esmi, thanks for posting these excellent guidelines for theme developers!
All these guidelines and tips are also very useful for pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party developers.
I hope the developers of the major plugins and frameworks take the time to read this.

Maybe a note at the top to encourage reading: everything that’s good for accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) is good for SEO too 😉

Some of my thoughts on the post:

Move Validation to the top of the list ( if only plugin developers would validate, life would be so much easier..)

Images:
In stead of decorative images (null alt) write
decorative images (alt=””)

Readability:
typo Tthe (second bullit)

Form Markup:
I didn’t know this: “any text that uses plain

tags may be ignored”
Can’t text be put in any other element then label or input inside a form?

Readably:
Quote: If you are using custom fonts, embed them in your theme so that you are not relying on a 3rd party site for font delivery.
Maybe only say :
“If you use a 3rd party site for fonts, check that the text is still readable if the fonts are not available.”
The fact that some fonts are hosted 3rd party is no accessibility issue on it’s own. (I use Google fonts a lot.)

The anchor link to the color blindness simulator doesn’t work.

Cross-Browser Testing: Add Chrome to the list?

Comments are closed.

About Us

How you can help

Learn More

Accessibility for Theme Developers: First Draft Complete

About Us

How you can help

Learn More

Share this: