Make WordPress Accessible

Updates from March, 2013 Toggle Comment Threads | Keyboard Shortcuts

  • esmi 8:40 pm on March 15, 2013 Permalink
    Tags: 3.6, ,   

    WordPress 3.6 alpha Testers 

    You might want to consider installing the MP6 plugin to get a sneak preview of the new user interface. Thus far, I’ve noted 3 areas of concern:

    1. The contrast on “Collapse Menu” needs to be pushed up a little to #888
    2. Post revision comparisons. Not sure I’m comfortable with red-on-red and green-on-green. At present, the contrasts are way too low at 2.7:1 (heck — even I’m having problems reading the texts).
    3. Ditto the text for inactive plugins on the Plugins page with only a contrast ratio of 2.8:1. And absolutely no way to “highlight” (increase the contrast) on the text without a mouse.
     

    • Jen Mylo 2:15 pm on March 16, 2013 Permalink | Reply

      Can you make trac tickets for each of these?

      • esmi 5:39 pm on March 18, 2013 Permalink | Reply

        Done. Tickets #23809, #23810 and #23812 created.

      • Helen Hou-Sandi 3:29 am on March 20, 2013 Permalink | Reply

        I don’t think Trac is the right place for things specific to MP6 as a plugin – it’s not in core, and it’s not being developed with 3.6 in mind. It’s a little distracting, I don’t think MT/other contributors are looking for feedback there, and we can’t really say that something got fixed against a given milestone. I’d say stick to their office hours or Make UI for now.

    • _Redd 4:45 pm on March 17, 2013 Permalink | Reply

      With my limited understanding of accessibility issues, there’s much for me to explore, but as someone with some training in Art, I can say that, in terms of visually “signaling” that this part of the screen has a different functionality from the rest of it, this is an exponential improvement. I hope we can keep this.

      • _Redd 7:34 pm on March 17, 2013 Permalink | Reply

        …sorry, the point above to mean, I think this will help those with cognitive disabilities……as far as the application towards those with other disabilities, I am still investigating.

  • 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 | 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 | 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 | 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 | 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 | 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 | 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 | 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 | 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 | 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 | 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 | 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?

  • esmi 12:00 pm on March 5, 2013 Permalink
    Tags: ,   

    Accessibility for Theme Developers 

    As part of the larger WordPress documentation project, I’ve put together a very rough first draft of an accessibility section for the theme developers’ handbook. It still needs a lot of fleshing out as I’m approaching this from the perspective of someone who doesn’t know anything about web accessibility. So I feel that we need to not only tell theme developers what to do but how and why.

    That said, is the draft missing anything major — bearing in mind that we do not want to overwhelm theme developers?

     

    • _Redd 1:07 pm on March 5, 2013 Permalink | Reply

      Of course this is awesome, but in your guidance for POUR criteria, what do you think of making specific reference to the need for a:focus on items? I know that I thought I was conforming to ADA requirements before joining this group, and have come to understand its importance.

      I think too, that knowledge is spreading because of the discussions in this group. For example, take a look at what Helen said about CSS and the impact of using display:none in this ticket on JQuery. We really need to thank her (as well as the other developers).

      The point is, that the information, when made available, is spreading and doing good–for me personally, the simple knowledge gained about the importance of a:focus has had tremendous impact on my styling, and maybe we could impact others in the same way if we put specific mention of a:focus through these guidelines.

      Just a thought, from someone who’s still learning a LOT!

      • _Redd 1:24 pm on March 5, 2013 Permalink | Reply

        Also, would it be too much to add specific mention on title attributes? Title attributes WAC blog That’s another thing that confused me greatly, and something I made a point to include before joining this group and learning the things I did. And again, I think the information is spreading.

        Ticket on Title Attributes

      • _Redd 7:13 pm on March 5, 2013 Permalink | Reply

        Also, what about a way to increase font size if necessary?

        And regarding color, I’m given to understand that it’s not just about color contrasts, but about color schemes too. Black text on a white background has great visibility, but is actually TOO hard to read for some people–white text on a black or dark blue background is easier for some people to read, though technically speaking, the contrast is not as great.

        • esmi 12:38 pm on March 6, 2013 Permalink | Reply

          I’d argue that, these days, this is best left to the user agent, Most current browsers have a decent Zoom option and I think there’s a point when the individual user has to take responsibility for learning how to use their own software. Plus, there are some plugins that can handle this.

          That said, should be still be pushing theme developers away from using pixels to define font sizes?

          • _Redd 1:07 pm on March 6, 2013 Permalink | Reply

            I absolutely agree that theme developers should not be using pixels to define font sizes….it’s a fundamental design issue in today’s modern pages.

          • toscho 4:08 pm on March 8, 2013 Permalink | Reply

            Zoom doesn’t work well with images, and you have to set it on every page. People who cannot read tiny fonts use a setting for a minimum font size in their browsers usually (mostly between 16 and 20px).

            An accessible theme should not break in these cases.

        • _Redd 1:09 pm on March 6, 2013 Permalink | Reply

          Doh! I forgot to make the “point” about all that talk about color schemes—-which is, should an option for choosing different color schemes be considered?

          • esmi 1:36 pm on March 6, 2013 Permalink | Reply

            I’d argue that this is beyond the remit of the average theme & is best left to specialised themes or plugins.

      • esmi 12:22 pm on March 6, 2013 Permalink | Reply

        what do you think of making specific reference to the need for a:focus on items?

        Thanks for the reminder. I’ve added this to the Links section which is now broken down to cover text, highlighting and underlining.

    • Joe Dolson 5:20 pm on March 5, 2013 Permalink | Reply

      In the section on Links, I think it’s worth mentioning that it is acceptable to hide the article title in a ‘read more’ link, as long as the method of hiding leaves the text available to screen readers. I think that there’s an issue with developers leaving this text out completely because they don’t want to see it, and don’t understand that it really is only necessary for non-visual users, and does not need to be displayed.

      • Joe Dolson 5:23 pm on March 5, 2013 Permalink | Reply

        Also, it’s worth noting that under most doctypes, ARIA attributes will cause validation failures, but it’s more valuable to use ARIA than to be valid.

      • esmi 12:48 pm on March 6, 2013 Permalink | Reply

        Added.

    • are.schjetne 12:58 pm on March 6, 2013 Permalink | Reply

      It’s a good start! But you have to look at how it can be done and should be done, not how you would do it.

      You also have to add examples on how it could be done and when it’s done wrong, you could also add a link to another reference that explains it more detailed, for example w3.org, developer.mozilla.org, whatwg.org.

      When you say that this is for the theme developers, you mean people that know HTML, CSS and/or more stuff(php, javascript, jQuery and so on) or are you aiming for the people that don’t know basic HTML and CSS?

      Also drop the screen reader thingy, I would not recomand a newbie theme developer to start with screen-reader-friendly themes.

      • esmi 1:39 pm on March 6, 2013 Permalink | Reply

        When you say that this is for the theme developers, you mean people that know HTML, CSS and/or more stuff(php, javascript, jQuery and so on)

        Yes.

        Also drop the screen reader thingy, I would not recomand a newbie theme developer to start with screen-reader-friendly themes.

        Sorry? This is about how to create a more accessible theme. And that means including access for screen reader users. You can’t “drop it”!

      • ceo 3:15 pm on March 6, 2013 Permalink | Reply

        Also drop the screen reader thingy, I would not recomand a newbie theme developer to start with screen-reader-friendly themes.

        Uh, that would basically defeat the purpose entirely of making a theme accessible if you didn’t work towards making it usable via a screen reader. That’s like saying you want to build a theme that can be viewable on mobile devices without making it responsive.

    • andyvaughn 7:07 am on March 8, 2013 Permalink | Reply

      I’d recommend adding “skip links” as important – especially for blogs with sidebar navigation. (apologies if wrong place to comment, first timer)

    • andyvaughn 7:16 am on March 8, 2013 Permalink | Reply

      Also, what about document size and accessibility? Unnecessary markup, script bloat, site-wide function calls, and heavy design imagery reduces accessibility due to extra-long load times.

      • esmi 9:12 am on March 8, 2013 Permalink | Reply

        Hmm… I’d argue that these are really usability issues as they can impact upon anyone — as opposed to people with a specific disability.

    • Joseph Karr O'Connor 7:26 am on March 8, 2013 Permalink | Reply

      Everyone, please meet andyvaughn who just joined the group and I notice he’s jumping in feet first:-) Welcome Andy! Andy connected with us via Twitter account @WPAccessibility which I am using to publicize our efforts.

      • esmi 9:13 am on March 8, 2013 Permalink | Reply

        Welcome, Andy :) Check your email for an invitation.

    • toscho 4:11 pm on March 8, 2013 Permalink | Reply

      One addition: Themes must not use accesskey and tabindex attributes in front end or back end.

      To create a predicable tab order write proper markup.

    • esmi 5:00 pm on March 8, 2013 Permalink | Reply

      Both already added

  • esmi 12:08 pm on January 24, 2013 Permalink
    Tags: animation, sound   

    Don’t “Let It Snow.” How Autoplays Can Disable Visitors to Your Website

     

    • Cyndy Otty 12:18 pm on January 24, 2013 Permalink | Reply

      Thanks for posting this for me, @esmi! I’m not nearly awake enough to function yet.

      Anyway, one thing is, for particular blogs on WP.com the blog owner can opt out of the snow feature. And it does save the selection each year.

      When I am more awake/have the time I want to see if this is still something that would fall out of compliance with WCAG.

      • Ipstenu (Mika Epstein) 6:34 pm on January 24, 2013 Permalink | Reply

        Opt out vs opt in, though… This should be opt-in across the board IMO.

        • Cyndy Otty 2:18 am on January 25, 2013 Permalink | Reply

          Agreed. I just wanted to clarify that it’s not on with no ability to change it.

      • Hew 1:12 pm on February 5, 2013 Permalink | Reply

        Hi all,

        Just FYI, the snow is in fact opt-in at WP.com. It’s off by default.

      • Hew 2:26 pm on February 5, 2013 Permalink | Reply

        Additional detail (h/t Westi): the default behavior is opt-in per blog via Settings->General in each dashboard, but WP.com also has a per user opt-out override on top of that via the WordPress.com user personal settings page.

    • Nelson 12:46 pm on January 24, 2013 Permalink | Reply

      esmi, thank you for posting this–thank you VERY much. Cyndy, I’ll be looking forward to anything and everything you find out concerning compliance with WCAG. Thank you both, yet again!

    • esmi 12:54 pm on January 24, 2013 Permalink | Reply

      @Nelson: Have a look at WCAG guideline 152. It references gifs but would cover any animation displayed on a site.

      • Nelson 1:06 pm on January 24, 2013 Permalink | Reply

        This is a super, and super-timely resource for me as I set up the site….thank you, yet again, esmi.

    • Nelson 6:19 pm on January 24, 2013 Permalink | Reply

      Just to let you know, I sent this article around at work, and comments are coming in about it. The article is awesome because it really personalizes the hardships; it’s not just about “more” technology. It really helps readers to understand what’s going on. This was a great choice!

    • Sharon Wachsler 2:28 am on February 5, 2013 Permalink | Reply

      Howdy! I’m very excited to see this thread cuz I wrote that post!
      Actually, I was coming over here to post about this issue and ask what people can do to help. I’m about to cross-post that article (with some updates and beautification) at AbilityMaineBlog.blogspot.com and I wanted to include suggestions about advocacy on the “Let It Snow” issue. So, do you have suggestions for people to help make the feature an opt-in versus an opt-out?
      Thanks very much for your assistance. It’s very gratifying to see that this topic is already under discussion.
      Peace.

      • esmi 11:27 am on February 5, 2013 Permalink | Reply

        Since this is a wordpress.com issue, there is a limit to what we can suggest in terms of making this an opt-in feature. That said, we already have one wordpress.com person here, so we know that at least one person is aware of these issues over there but I’ll try pinging someone else over at Automattic to see if we can get a bit more traction on it.

        Sorry I’ve been a little quiet of late. Still trying to get over a nasty bout of flu. :(

        • Jen Mylo 1:02 pm on February 5, 2013 Permalink | Reply

          I’ll mention this thread to the .com folks.

          • Sharon Wachsler 3:51 pm on February 7, 2013 Permalink | Reply

            @esmi, sorry about the flu. It’s been a horrible cold and flu season this year. Hope you’re feeling better soon.
            Thanks for the clarification. I keep getting confused about which boards are for .com and which for .org. I appreciate your support on the issue.
            @Jen thank you also for your help.
            I guess I’ll just put in my new post that WP folks know about it and it’s being worked on. I do like to offer concrete steps people can take, but it sounds like in this case, there’s not much to offer.

  • esmi 3:12 pm on January 15, 2013 Permalink
    Tags: ,   

    Aaron Jorbin is suggesting that the new Twenty Thirteen should be designed and built “accessibility first”. He outlines exactly what he means by this in What I want to see in the Twenty Thirteen theme. I think this is an initiative we should all support 100%.

     

  • esmi 1:14 pm on September 27, 2012 Permalink  

    Accessibility for Non-Technical Site Owners 

    As part of the new User handbook being created over at
    Supporting Everything WordPress, I’ve put together an introduction to web accessibility.

    This is intended to be far less technical and in-depth than its companion page in the Codex. The intent is to get site authors thinking about how they add content rather than just the final look of their pages.

    On that basis, I’ve just focused on using headings, images and links as well as general readability.

     

    • Bachsau 6:58 pm on September 29, 2012 Permalink | Reply

      One really important thing on this topic is the autoupdate of twentyten, twentyeleven and twentytwelve themes. People with not FTP access and knowledge are stuck a with an english frontend even on localized versions of WordPress. Please include the locals in themes packages, so autoupdate of themes work correctly.

      • esmi 10:23 am on October 1, 2012 Permalink | Reply

        That has nothing to do with accessibility.

    • Cyndy Otty 2:53 am on September 30, 2012 Permalink | Reply

      I don’t know if you want to mention this, but it is worth noting (in my opinion) that web accessibility is not solely for disabled persons, but can actually be beneficial on a broader scale, i.e., more ability and ease of use across browsers and mobile devices, etc.

      • esmi 10:25 am on October 1, 2012 Permalink | Reply

        Good point! I’ll see if I can work that in too.

  • esmi 10:28 am on May 4, 2012 Permalink  

    http://blog.rrwd.nl/2012/03/23/how-accessible-is-the-wordpress-cms-for-a-blind-content-manager/

     

  • esmi 1:36 pm on May 3, 2012 Permalink
    Tags: 3.3.2   

    Some interesting issues brought up by a blind user on the wordpress,org support forums: http://wordpress.org/support/topic/plugin-dantotube-some-accessibility-fix-suggestions

     

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