WordPress.org

Make WordPress Accessible

Updates from March, 2013 Toggle Comment Threads | Keyboard Shortcuts

  • Joe Dolson 10:59 pm on March 28, 2013 Permalink
    Tags: , theme audit   

    I’ve been chatting with Chip Bennett via the Theme Review list about the Theme Audit guidelines. With his feedback (which was from the theme author and reviewer perspective, and very valuable) and the feedback from the comments on my previous post, I’ll be working on the next version with a variety of changes of various types. He’s going to be proposing some changes to the general guidelines that will obviate the need for a couple of the elements in the accessibility audit guidelines.

     
    • joe 2:26 am on April 1, 2013 Permalink | Log in to Reply

      I think it would be worthwhile to still mention the accessibility guidelines anyway, perhaps a cross reference or state that it also satisfies accessibility points.

  • Graham Armfield 12:37 pm on March 28, 2013 Permalink
    Tags: , , , , , , , ,   

    Add Media Panel and WordPress 3.6 – A Simple Solution? 

    The beta version of WordPress 3.6 is very close now and the chances of significant extra functionality being included must be slim. But, the Add Media Panel introduced in 3.5 is still inaccessible and the trac tickets raised on this are still untouched.

    This is a real problem as the Add Media Panel is such a key piece of functionality.

    However, from our IRC chat yesterday the germs of a simple solution may have emerged – a solution that could maybe make the functionality accessible to keyboard and screen reader users. We just need someone to give it a try.

    (More …)

     
    • _Redd 12:46 pm on March 28, 2013 Permalink | Log in to Reply

      Just to THANK you for the amazing work that went into this…..the path you’ve outlined here gives us a real way to pursue this, and to help out. More to come, but again, thank you!

    • Joe Dolson 3:02 pm on March 28, 2013 Permalink | Log in to Reply

      This is a great suggestion — and should be very simple to tackle.

      Do you think that the img should also use the aria-labeledby attribute to associate the label? I haven’t tested this, but I’m not sure offhand what behavior is exhibited by a screen reader in associating a label with a non-form field by ID.

      • GrahamArmfield 9:55 pm on March 28, 2013 Permalink | Log in to Reply

        I had thought about that Joe and it may be a better solution. The code I propose was based on an example within that Mozilla site, but the working example they link to did it using a different technique.

        One of the things I was keen to avoid was ‘double voicing’ by screen readers that I know can be annoying – hence the blank alt attribute too.

        I guess the key thing is to find someone who can prototype this like @lessbloat did with the Custom Menu solution. We can then test it with various AT.

    • Tony Scott 9:16 pm on March 30, 2013 Permalink | Log in to Reply

      Great work Graham – many thanks!

    • GrahamArmfield 1:31 am on April 3, 2013 Permalink | Log in to Reply

      There has been some action on this issue. See the discussion and revised proposal on trac #23560.

      • _Redd 3:02 pm on April 3, 2013 Permalink | Log in to Reply

        Graham, what you and lessbloat have done on ticket #23560 is nothing short of amazing, absolutely amazing.

        Do I understand that there’s a possibility this can go into 3.6?

        Are you going to be able to make it to the IRC chat today?

        • Graham Armfield 3:10 pm on April 3, 2013 Permalink | Log in to Reply

          I’m really hoping we can get this into 3.6 with @lessbloat‘s help. It doesn’t address all the potential accessibility issues but at least it’s going to be a lot more accessible than it is now.

          Yes, I’m intending to be in IRC chat later.

          • _Redd 3:25 pm on April 3, 2013 Permalink | Log in to Reply

            When I last saw the ticket, you still hadn’t been able to have one to test. I can’t “see” the ticket now, so I don’t know if you’ve been able to test. As a person who is really, really stupid to this, I tried to incorporate his diffs into my 3.6 alpha test site….would you like to get into it to look around?

            I don’t know enough about screenreaders to even approach this…

            No promises that I did anything right, but due to the time crunch, I’m offering it to you for screenreader evaluation….

            Test Site

          • _Redd 3:26 pm on April 3, 2013 Permalink | Log in to Reply

            Looks like I set up the hyperlink wrong

            http://red-hound.com/test/addmedia/

            Let me know if you want to get in there, I know EVERYONE is short on time….

            • Graham Armfield 3:32 pm on April 3, 2013 Permalink

              That would be superb if you could let me have access to the site. Please email me the logon details – graham.armfield@coolfields.co.uk and I’ll give it a go.

              One day I’ll have to see if I can get a suitable environment together but it’s a little daunting from a standing start.

            • _Redd 3:33 pm on April 3, 2013 Permalink

              Coming your way, standby

            • _Redd 3:42 pm on April 3, 2013 Permalink

              You should have an email from me….when I tried to create you as a user and give you a password, it said the name was reserved….I think it is waiting for your confirmation email….let me know how it goes,

            • Graham Armfield 4:14 pm on April 3, 2013 Permalink

              OK I’m in. Will test shortly.

            • _Redd 7:44 pm on April 3, 2013 Permalink

              Hi Graham, I’ve redone the media-views.js file, and it is yours to test. I sent you email with a file called “modified-media-views.js” so you can double check it if you like. Not sure if your spam folder will kick it back.

              I’m watching for your response with baited breath!

            • _Redd 7:56 pm on April 3, 2013 Permalink

              OK, thank you Graham, at least, know that you have a server to play with. We’ll work it out. I’ll see you on the IRC chat.

      • Graham Armfield 4:04 pm on April 4, 2013 Permalink | Log in to Reply

        @lessbloat has made some further changes after our testing yesterday which have further contributed to the accessibility.

        It is now possible to select/deselct with the space bar as well as the Enter key. This should enable (hopefully) all screen reader users to select the items as if they were checkboxes – without having to rely on the ‘pass-through’ keystrokes.

        Also, he has improved the visibility of keyboard focus on the media files so that anyone using keyboard, or voice recognition users emulating tabbing will be easily able to see where they are.

        Within the trac ticket #23560 I have asked him to make one further change – that is to place the image title within the aria-label attribute rather than the file name. That way, if you’ve given the file a meaningful title or alternate text when the file was first uploaded it will be presented to the screen reader.

        So far, comments received have indicated in favour of getting these changes included within 3.6. I’m not sure how this is achieved – is it automatic, or is there a further process that needs to occur.

        If anyone has objections then now is the time to express them I guess.

    • _Redd 5:25 pm on April 4, 2013 Permalink | Log in to Reply

      Only writing here to say we can’t thank the two of you (lessbloat and yourself) enough. This is mind-blowing! What a huge accomplishment!

  • Joe Dolson 3:15 pm on March 19, 2013 Permalink
    Tags: audit,   

    Theme accessibility audit guidelines update 

    Hey, all. I’ve updated the theme auditing guidelines and they have now been added to the theme reviewer’s documentation. Take a look at the requirements for the #accessibility-ready theme tag and comment back here with any suggestions or changes.

    Note that these guidelines are in addition to the rest of the theme guidelines, and there are many quality guidelines already established that don’t need to be part of the accessibility audit.

     
    • _Redd 5:49 pm on March 19, 2013 Permalink | Log in to Reply

      You ROCK! As do these guidelines!

      Do you think a requirement to have controls for audio, video be included in the guidelines?

    • Joe Dolson 5:55 pm on March 19, 2013 Permalink | Log in to Reply

      I’ll be honest, I find it extremely unlikely that a theme that had autoplaying video or audio with no controls available would ever be accepted to the theme directory. It’s also possible that including any kind of video/audio player crosses the Presentation/Functionality guideline, and wouldn’t be allowed regardless. I’ll check on that.

      • esmi 5:02 pm on March 20, 2013 Permalink | Log in to Reply

        What about sliders? Should they start automatically?

        • Joe Dolson 5:22 pm on March 20, 2013 Permalink | Log in to Reply

          Perhaps adding a generic statement addressing the behavior of media resources, to the effect that media resources should not, by default, auto start or change without user intervention. Would that cover these grounds effectively?

    • GrahamArmfield 6:32 pm on March 19, 2013 Permalink | Log in to Reply

      Nice piece of work Joe.

      I have a couple of comments:

      1. Re colour contrast… Would it be appropriate to reference a Colour Contrast Analyzer tool here? The contrast algorhythms are fairly complex and a tool such as the one from the Paciello Group is very easy to use.
      2. I’d say there are some situations where tabindex=0 would be allowed.

      Hope that helps.

      • esmi 5:03 pm on March 20, 2013 Permalink | Log in to Reply

        1. We’ve got a load of links here for useful tools, so perhaps a link back to the page on this blog would be the best way forward?

        2. Did you mean negative tabindexing?

        • Joe Dolson 5:25 pm on March 20, 2013 Permalink | Log in to Reply

          I think that a link back here for testing resources is a good plan, and I also agree that tabindex=0 should be allowed on non-focusable elements. Tabindex of -1 is already permitted.

    • Joe Dolson 10:06 pm on March 20, 2013 Permalink | Log in to Reply

      I’ve added comments regarding media resources behaviors, tabindex equals zero, and a link back to the Useful Tools page. That should cover everything discussed here; but let me know if you have more comments!

    • joe 10:45 pm on March 24, 2013 Permalink | Log in to Reply

      I love the accessibility-ready tag. Hits the right note and reminds the user that a11y is not a checkbox or developer only task. Should there be some ability to add specific alt text to a heading image, in particular if the theme supports multiple header images displayed randomly. not all images are decorative and empty alts on headers isn’t very a11y.

    • James Craig 6:52 pm on March 25, 2013 Permalink | Log in to Reply

      A few more pieces of feedback:

      1. A “skip link” should not be required if the author uses WAI-ARIA landmark roles.
      2. Forms section should require use of @required or @aria-required, and should encourage use of @aria-invalid while displaying field validation errors.

    • James Craig 6:57 pm on March 25, 2013 Permalink | Log in to Reply

      Looks like my first post didn’t go through. If you’re intending to use those bolded keywords as normative RFC-2119 requirements you need a few changes:

      1. Add a normative requirement section explaining that. e.g. http://www.w3.org/TR/wai-aria/normative
      2. Consistency case them. e.g. “MUST NOT” not “must NOT”
      3. Change the passive requirements to active ones clearly indicating to whom the requirement applies. e.g. “Theme authors MUST include alt values for images.” not “Images MUST have alt values.”

    • Léonie Watson 2:40 pm on March 26, 2013 Permalink | Log in to Reply

      Great to see accessibility in the theme guidelines Joe.

      I’d be inclined to rename the “Skip links” section to “Keyboard navigation”, and make the content less technique specific. For example:

      “Themes must include a mechanism that enables people to move to a particular area of the page using the keyboard. For example ARIA landmark roles or a skip link.

      ARIA landmark roles for banner, main, navigation, complimentary, search and contentinfo should be included. If the ARIA main landmark and navigation roles are used, a skip link need not be included.

      If a skip link is included it may be hidden off-screen initially, but must always be available to screen readers and must become visible onFocus for sighted keyboard users.”

    • Joe Dolson 3:15 pm on March 26, 2013 Permalink | Log in to Reply

      Hey, James and Leonie — I’m not sure I’m comfortable with removing the skip links requirement if WAI ARIA landmarks are provided. While WAI-ARIA landmarks are great for screen readers, they don’t provide any navigation benefit for sighted but keyboard-dependent navigators, that I know of. If there’s something I don’t know there, however, please do let me know!

      In terms of any RFC-2119 factors, I think that’s an issue for the WordPress documentation team to address — the entire document is quite inconsistent on all points, so it’s no great benefit to a single section conformant. But we can raise the question.

      The voice change is a good suggestion, however – thanks.

    • Rian Rietveld 9:02 am on March 27, 2013 Permalink | Log in to Reply

      Great work Joe!

      My comments:
      1. About the Headings: maybe replace “use a reasonable heading structure” for “use a semantic heading structure”.
      2. Add links to examples (like solutions of the read rome…” link or how place text offscreen), in stead of a link to a list of links that link to pages with links. Some developers (like me) are more comfortable with a quick example instead of reading though a lot of documentation first.
      3. About the Headings, maybe replace “use a reasonable heading structure” for “use a semantic heading structure”.
      4. I can see the HTML code for the abbr HTML also for CSS.
      5. I agree with your opinion: “I’m not sure I’m comfortable with removing the skip links requirement if WAI ARIA landmarks are provided”. Leave it to the user what way to navigate, not all users of screen readers use roles.
      6. Maybe add a requirement that inline style for mark-up should be avoided.

      • Joe Dolson 3:04 pm on March 27, 2013 Permalink | Log in to Reply

        We actually want to explicitly avoid requiring semantic heading structures, because the movable content model in many WordPress themes makes that almost impossible to guarantee — and the most important thing, ultimately, is having headings used correctly, rather than having a proper semantic structure to the headings. Developers are certainly encouraged to exceed the guidelines, but the guidelines are really intended to be fairly minimal.

        Adding links to examples in some cases is intended — but will be developed over time.

        I’ve noticed the HTML issue in the docs; it’s in markdown, and I’m not fully comfortable with what it supports yet…

        We feel that inline styles are ultimately a code quality guidelines, and should be dealt with in the ‘Code Quality’ portion of the theme review, rather than in the Accessibility guidelines. Inline styles are not, by themselves, an accessibility problem, as far as I understand.

  • Graham Armfield 10:52 am on March 18, 2013 Permalink
    Tags: , dialogs, popups,   

    Accessible Dialogs and Popups 

    It seems there are an increasing number of areas where dialogs or popup panels are used to alert the user about occurrences and perhaps demand some action from them. Examples include the Autosave and Post Locking dialogs #23697 and Login Expiration #23295 – as pointed out by Joe Dolson.

    Within #23697 @azaozz responded to some comments of mine re accessibility by asking “Is there anything else we should be doing to make these dialogs better?”

    My response to him was:

    1. When the dialog opens, keyboard focus must be transferred into a meaningful object within the dialog – suggest a heading that explains purpose of dialog. This item can be given tabindex=0 to allow it to receive focus both by scripting and tabbing.
    2. The purpose of the dialog should always be visible.
    3. Whilst the dialog is open, functionality will be needed to tidily cope with users tabbing beyond the controls/buttons in the dialog, or reverse tabbing before the entry point. Tabbing can either cycle within dialog if it’s important that user responds, or that tabbing outside confines of dialog closes the dialog.
    4. Whenever dialog is closed, keyboard focus should be returned to somewhere sensible – maybe the link/button that opened dialog in the first place, or to top of a new page if one is opened.

    Does that sum it up, or is there more that could be added to that list?

     
    • _Redd 11:50 am on March 18, 2013 Permalink | Log in to Reply

      Graham, please excuse my ignorance on this, but regarding Ticket #23295, there is a reference to using an iframe as a solution.

      To work around that we can use an XHR instead of having an iframe (XHRs can be used to set cookies). Another technique is to create an iframe then submit a

      with target=”iframe-name”.

      It’s my understanding that iframes create problems for, at a minimum, screen readers…..

      1. Is the assumption that an iframe creates problems for assistive technology a correct one?
      2. Can an iframe be tweaked so that it is “friendly” to assistive technology?
      3. If so, is that “tweak” part of the solution referenced in the ticket?
      4. If not, is this significant enough to recommend against the iframe solution?

      Thanks for EVERYTHING

    • toscho 1:00 pm on March 18, 2013 Permalink | Log in to Reply

      Every (pseudo-)popup must close when the user hits ESC.

      • Andrew Ozz 10:56 pm on March 18, 2013 Permalink | Log in to Reply

        In this particular case the “popup” warnings/dialogs cannot be closed without making a choice/selecting an action. For the “post lock taken over” dialog there is only one action possible (for now?) but it shouldn’t be triggered by escape imho.

        All three warning dialogs (post locked, post lock taken over, login expired) are modal as the user is required to make a choice or perform an action. They don’t have a “Cancel” option.

        • Joe Dolson 3:05 pm on March 19, 2013 Permalink | Log in to Reply

          I agree that these options shouldn’t be avoidable; adding a method to avoid the decision would not help anybody. That’s not an accessibility issue, it’s a workflow issue, and the workflow requires that the user receives information about the change of state in the application and makes a conscious decision what to do about it.

          But, for any modal contexts that can be avoided, being able to close via the esc key is a standard key mapping and should be available, certainly.

    • gogreener 2:23 am on March 19, 2013 Permalink | Log in to Reply

      Not an essential feature, but a “nice-to-have” one: any image-links used to close the popup could have alt text of “Return to [page/section name]” or similar, instead of “Close”. Close is not as meaningful if you weren’t aware that anything had opened, while “return to…” makes more sense when you’ve temporarily stepped out of the normal task flow.

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

      Can you make trac tickets for each of these?

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

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

      • Helen Hou-Sandi 3:29 am on March 20, 2013 Permalink | Log in to 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 | Log in to 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 | Log in to 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 3:02 pm on March 14, 2013 Permalink
    Tags: , , ,   

    IRC Meeting: March 13, 2013 

    We had a little mix-up with the meeting time this week, due to the change to Daylight Savings Time in the US, so this meeting report may be a little shorter than usual.

    However, the weekly meetup time remains at 20:00 UTC until the end of the month — when we may review and adjust it. Remember that you can convert UTC time to your local time at Worldtimeserver.com.

    (More …)

     
  • Joe Dolson 2:52 pm on March 9, 2013 Permalink  

    If anybody has a chance to take a look at the progress on autosave and post locking that would be valuable – I have some concerns about whether the context changes when sessions have expired will be announced, but haven’t had time to test it at all. Ticket 23295

     
    • esmi 2:11 pm on March 14, 2013 Permalink | Log in to Reply

      Just lodged a general note of concern on the ticket. We really do need to test this out with our screen reader users.

    • Graham Armfield 7:01 am on March 16, 2013 Permalink | Log in to Reply

      I have made some comments on #23697 (Check and refresh post locks with heartbeat) also. There’s a proposal for a couple popup to be generated where locking conflict is occurring. I have asked @azaozz to confirm that focus will be moved into any popup that gets generated, and that focus goes somewhere sensible when a button is actioned.

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

    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?

  • esmi 4:22 pm on March 7, 2013 Permalink
    Tags: , , ,   

    IRC Meeting: March 6, 2013 

    Another small but lively meeting. We also had the opportunity to welcome our newest member, @shaun_10up – a relatively new core contributor. I think we’ll be keeping him busy over the next few weeks! 🙂

    Custom menus

    Thanks to contributions from @lessbloat, @ceo and @quanin, we’re now seeing real, positive, progress on Trac ticket #14045. This greatly increases the chance of WordPress 3.6 being shipped with a more accessible custom menu system. Thank you for all of your hard work on this.

    (More …)

     
  • 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 | Log in to 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 | Log in to 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 | Log in to 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 | Log in to 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 | Log in to 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 | Log in to 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 | Log in to 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 | Log in to 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 | Log in to 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 | Log in to 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.

    • are.schjetne 12:58 pm on March 6, 2013 Permalink | Log in to 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 | Log in to 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 | Log in to 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 | Log in to 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 | Log in to 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 | Log in to 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 | Log in to 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.

    • toscho 4:11 pm on March 8, 2013 Permalink | Log in to 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 | Log in to Reply

      Both already added

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