WordPress.org

Make WordPress Accessible

Tagged: documention Toggle Comment Threads | Keyboard Shortcuts

  • hearvox 2:28 pm on February 6, 2016 Permalink
    Tags: documention,   

    Accessibility Quick Start Guide in draft: needs vetting 

    The WordPress Accessibility Handbook now has a draft of a Quick Start Guide. The doc needs edits, comments, and vetting.

    We intend this as a resource for developers to quickly grab WordPress-oriented code examples and a11y guidelines. Let’s make sure everything is accurate and clearly explained, and that nothing a11y-critical for WP dev is missing. (This process might also help us identify which topics need further explanations in other Handbook sections.)

    Please review the draft and leave your comments on this post.

     
    • RachieVee 2:29 pm on February 8, 2016 Permalink | Log in to Reply

      I love that we have this now! And I really like the structure to cover all the basics. I do find it a bit long or hard to read it areas for skimmers. I imagined the quick start to be a “quick” checklist of tips whereas the rest of the handbook can go into depth for those that want to go down that route. I like how the theme handbook avoids large blocks of code: https://developer.wordpress.org/themes/functionality/accessibility/

      And I like how the a11y project offers quick tips and then the “how to’s” go more into depth.

      http://a11yproject.com/

      I feel like we can keep the bullet points and then use those code examples in new posts within the handbook that get linked to from the quick start. This way the quick start can still be treated as a checklist of sorts, don’t do this, make sure you do this, and when the reader wants to know the how’s and why’s if it’s not a quick explanation, there will be another post to provide that.

      I think my favorite part is the screenshots of how a screen reader shows links that aren’t worded accessibly. I’d love to see more examples of how screen readers behave or what it’s like to try and access something that wasn’t made very accessible like sites without :focus or sites that aren’t using semantics properly. Trisha and I were discussing empathy recently, and I think it’s a great way to educate people. A lot of people just assume accessibility is hard to do and the people it’s built for are some rare group and small percentage in the web’s audience. I think the more we can remind others how close this hits to home and how we can make a difference one small change at a time, the more successful we’ll be in convincing people to learn more about accessibility. 🙂

      Ideally it’d be cool if each section in this quick start would link to one or more in-depth articles that cover those sections even deeper. Nice work so far!

  • hearvox 9:12 pm on December 28, 2015 Permalink
    Tags: documention,   

    WP a11y docs list 

    Here’s a collection of all the A11y resources I’ve found at WordPress.org sites (and two Google docs in use for drafting Handbook pages):

    Make WordPress Accessible blog
    https://make.wordpress.org/accessibility/

    Make WordPress Accessible> Accessibility Handbook
    https://make.wordpress.org/accessibility/handbook/

    (Draft: outline for A11y Handbook) Accessibility Contributor Handbook
    https://docs.google.com/spreadsheets/d/1tOYzFn9vc7Ff4yGBmDajelrl7XMDUz4PR5H2lB4exI4/edit?usp=sharing

    Make WordPress Accessible> Useful Tools

    Useful Tools

    WordPress Accessibility> Theme Patterns
    https://github.com/wpaccessibility/a11ythemepatterns

    Docs Handbook> Handbooks Style and Formatting Guide> Accessibility

    Handbooks Style and Formatting Guide

    Codex> Accessibility
    https://codex.wordpress.org/Accessibility

    Theme Handbook> Accessibility

    Accessibility

    Theme Review Handbook> Accessibility

    Accessibility

    Theme Review Handbook> Accessibility> #resources

    Accessibility

    Theme Review Handbook> Accessibility> Resources

    Resources

    Theme Directory> accessibility-ready tag
    https://wordpress.org/themes/tags/accessibility-ready/

    Plugin Directory> WP Accessibility
    https://wordpress.org/plugins/wp-accessibility/

    Plugin Directory> Access Monitor
    https://wordpress.org/plugins/access-monitor/

    (Draft: guidelines for Plugins) WordPress A11y Code Standards
    https://docs.google.com/document/d/1iySvDJ4duHYt6YlnnjnBNbU5LKAn1uRBMH8FKAfmswE/edit

    Accessibility code standards for WordPress core (similar to above)

    Accessibility code standards for WordPress core

     
    • hearvox 9:15 pm on December 28, 2015 Permalink | Log in to Reply

      We can use this list to try to maintain reasonably consistent phrasing in our explanations, code in our examples, and references in our various resources lists:
      https://make.wordpress.org/accessibility/useful-tools/
      https://make.wordpress.org/themes/handbook/review/accessibility/resources/
      https://developer.wordpress.org/themes/functionality/accessibility/#resources

    • Joe Dolson 9:55 pm on December 28, 2015 Permalink | Log in to Reply

      I’d take the WordPress.com support document out of this list; that document is controlled by Automattic, and is completely out of our hands. Also, can you provide a definition of what you mean by “WordPress-made”?

      • hearvox 10:49 pm on December 28, 2015 Permalink | Log in to Reply

        WP.com resource removed. “Wp-made” rephrased. What I mean is: all the a11y resources at WP.org sites, plus the two g-docs for planning a11y resources at WP; i.e., any pages we might find similar language or lists that we may want to keep consistent. (It’s mainly these pages, BTW, from which I’m pulling language and topics fro the Quick Start Guide.)

        • Joe Dolson 12:37 am on December 29, 2015 Permalink | Log in to Reply

          Thanks; I’m still not clear what the definition of “WP-made” resources is; it’s not written above, that I can see. I’m mostly asking because there are at least 2 resources up there that are my personal projects: Access Monitor and WP Accessibility. They’re certainly dedicated to WordPress, but they aren’t “WordPress Made” in any meaningful way.

          • hearvox 1:02 am on December 29, 2015 Permalink | Log in to Reply

            It doesn’t say “WP-made” anymore. Says: “Here’s a collection of all the A11y resources I’ve found at WordPress.org sites.” I included your plugins because there’s language, topics, and resources in them that might be of use when making a11y docs.

  • esmi 12:14 pm on March 8, 2013 Permalink
    Tags: documention,   

    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.

     
    • Dane Morgan 4:21 pm on March 8, 2013 Permalink | Log in to Reply

      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 Permalink | Log in to Reply

      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 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 WCAG standards might add a bit of muscle to the points.

    • esmi 6:09 pm on March 8, 2013 Permalink | Log in to Reply

      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 WCAG 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 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 Permalink | Log in to Reply

        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 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 Permalink | Log in to Reply

      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 Permalink | Log in to Reply

      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 Permalink | Log in to Reply

      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 Permalink | Log in to Reply

      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?

    • fingli 9:42 pm on March 12, 2013 Permalink | Log in to Reply

      May I suggest Total Validator http://www.w3.org/2001/sw/wiki/TotalValidator as another useful tool for checking 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 Permalink | Log in to Reply

      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 Permalink | Log in to Reply

      Hi @esmi, thanks for posting these excellent guidelines for theme developers!
      All these guidelines and tips are also very useful for plugin 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 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?

c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel
Skip to toolbar