Make WordPress Accessible

Updates from April, 2013 Toggle Comment Threads | Keyboard Shortcuts

  • esmi 1:46 pm on April 26, 2013 Permalink
    Tags: ,   

    IRC Meeting: April 24, 2013 

    We had another lively IRC meeting on Wednesday.

    3.6 Post Formats

    It was previously decided that both the video and audio post formats could benefit from an ability to add links to captions (for videos) or transcripts (for audio files) and some preliminary investigations were started to look at the possibility of submitting patches. However, as there has been some concern about the release schedule for 3.6 and the possibility that Post Formats might be removed from the release, this has been shelved until we hear further.

    (More …)

     

  • 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 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 …)

     

  • Graham Armfield 10:01 am on February 25, 2013 Permalink
    Tags: , , , ,   

    Add Media Panel – Accessibility Issues 

    I’ve raised this post as I feel that the issue of the Add Media panel accessibility needs some debate amongst the accessibility community.

    Last week I raised three WP trac tickets covering my take on the problems from the keyboard access, screen reader and VR aspects. They are: #23560 and #23561.

    The main problem as I see it is that it is not possible to select/deselect any of the media without using a mouse.

    The functionality primarily acts like a group of checkboxes – selecting one or multiple elements, with feedback that they have been selected. However, that is not how the functionality has actually been implemented – it’s a series of divs contained within an unordered list. There appears to be nothing to receive focus. There are links for each file, but the links appear empty although they are used to show the selected icon. These links are also initially invisible using CSS techniques that hide them from screen readers – hence the no tabbing into the images issue.

    Is the use of ARIA going to really be able to help here?

    When mouse users select an image they can update the attribute values for that image using the panel to the right – which updates its content automatically. Allowing keyboard users to quickly reach the attributes boxes would obviously be desirable – the alternative being tabbing through all the previously uploaded files.

    The media selector panel has been implemented with infinite scrolling, so on mature and/or larger sites with many images/files (I have one) the list of images gets bigger and bigger. From an accessibility perspective I’d favour paging over infinite scrolling, but what’s your take on that?

    Is this another area where bending the new functionality to include accessibility might be too much? Is this another place where an accessibility mode is going to be required?

    What do you think?

     

    • _Redd 2:24 pm on February 25, 2013 Permalink | Reply

      So, first of all, thank you for your breakdown as to exactly what is going on with the Add Media panel. I had no idea.

      1. I am not finding great support for ARIA in my other efforts. We should use it where ever possible, of course, but I think it is a mistake to depend on it.

      2. I am learning that, so much, too much, is mouse-dependent. It’s not just about making it accessible for the blind, it’s about the other users who can’t use a mouse, so this is something critical. How hard would it be to add a:focus to the CSS?

      3. While those who are blind may not need to see “images”, there is certainly a need to “see” the accessible pdf files, which are considered images. (Now I wonder if WordPress is stripping off, or blocking access from, the accessibility features that can be enabled in Adobe pdf files). So definitely, some sort of alphabetical sorting capability would be in order. That can’t be too hard with WordPress’s order_by functions, can it?

    • Donna W. Hill 10:00 pm on February 25, 2013 Permalink | Reply

      I recently purchased a domain from WP in order to have an online vehicle for promoting my upcoming novel, The Heart of Applebutter Hill. I am blind and use the Jaws screen reader and have both the IE9 and Firefox browsers. I have spent over a hundred hours in the past few weeks trying to figure out how to use WP efficiently and am starting to se some results. I’m not clear about the connection between WP.org and WP.com; some of the help files seem similar. If there is a connection, I thought you might be interested in my feedback. If not, I hope you will know to whom this information should be forwarded.

      The issue that has taken most of my time has to do with Media. My first suggestion for WP is to put together a concise Tutorial/Help topic addressing the definitions and description of the various types of images – header image, profile image, featured image, images inserted into posts and pages, attached and unattached images, permalink vs. File URL, the settings options for image size, which are editable, alternative options for uploading and inserting images and explainations of the difference between and the purpose of the file title, caption, alt tag and description. Currently, what WP has is incomplete, poorly described and scattered. That would help everyone. Beyond that, there should be a concise and easily located section about how WP currently works (or not) with access technology.

      When I realized that the Header image has such a weird width/heighth ratio, I opted for one of WP’s. In terms of uploading images, I find that the uploader, though squirlly, works. The option to upload media via e-mail is much better, but doesn’t work for all photos, though I haven’t yet figured out why.

      The next thing I got bogged down with was “Featured Image/Set Featured Image.” It’s so prominent in the image edit area, that I thought it was something that would show up inside the post or page. Once I realized that it was not, I moved on.

      Using the “Add Media” option from the edit field of a post or page brings up a page where you are supposed to be able to select and insert an image from those you have already uploaded into the body at the point of the cursor. This displays differently in IE and Firefox. In IE, there is a list of links, and Jaws says, “Link, deselect” for all of them, giving no indication what picture it’s talking about. In Firefox, there is a list which says it contains the proper number of image files, but only one is visible to Jaws. For instance, Jaws will say, “List of 9 items” and then, Link, Dog in Autumn Leaves,” followed by nothing else other than “list end.” For some reason, Jaws does read the file name in Firefox. Nevertheless, neither browser can actually be used to insert an image using Jaws.

      Since WP’s tutorials give this option pride of place, Jaws users may think it’s the only option. The best way to insert images in posts and pages that I have found is to use the alt m command from inside the edit field of the body of the post or page. It may seem at first that this option couldn’t possibly work. Using it causes Jaws to immediately jump out of forms mode, but WP apparently knows where the cursor was. Instead of going to the Media Library, “Alt m” opens a dialog in which WP requests certain information.

      The first thing it wants is the URL of the picture being inserted. It’s important to let screen reader users know that they should collect this information from the Media Library ahead of time and keep it in a document you can easily find offline. The next thing you need to know is that, despite the fact that in the Media Library the permalink for the image is right under the name and you really have to go on a hunt to find the File URL, it is the File URL that Word Press wants. Once it’s in the editfield and is Ok’d, another edit field appears requesting the alt tag. Even when the alt tag has been defined in the Media Library, it is not visible to Jaws in this edit field. I don’t know if it’s a Jaws or WP issue. Nevertheless, this is another use for the file information document, and when I copy the alt tag and paste it in, it works.

      The matter is further complicated for screen reader users by the fact that whether you use the permalink, which seems most obvious, or the File URL, which is correct, Jaws will recognize a graphic on the post or page, complete with alt tag. This promotes the illusion that you have been successful. Only when viewed by a sighted person do you find out that the permalink version is an empty box.

      The Media Library itself seems to be working for me better than you indicate in this post. The checkboxes at the top of each image’s section can be accessed with “x” or “shift x,” and one downarrow gets you to the link for the full list of edit options for that image. The search field also works.

      The other thing that would help navigation is to change the configuration of the major area of the Dashboard. If I downarrow through the page, I can tell that it is divided into sections with a major link followed by a list of corresponding links. It would be easier for screen reader users an no bother for anyone else to change this by making headings out of the primary link in each section — Posts, Pages, Media, Appearance, Settings and so on. If you don’t realize that “Media” shows up as both a section and under Settings, for instance, you can quickly get lost by using Jaws’ links list.

      • _Redd 1:07 pm on February 26, 2013 Permalink | Reply

        @Donna this feedback is amazing….thank you so much. For the record, as a totally sighted user, I also had trouble with understanding the featured image feature in WordPress. In fact, there is a ticket to that very problem for which developers are creating a fix.

        link to ticket for Featured Image

        Regarding the following:

        It would be easier for screen reader users an no bother for anyone else to change this by making headings out of the primary link in each section — Posts, Pages, Media, Appearance, Settings and so on. If you don’t realize that “Media” shows up as both a section and under Settings, for instance, you can quickly get lost by using Jaws’ links list

        I also encountered that same confusion as a totally sighted user, so I think there is real merit in what you are saying.

        @Graham @ceo I wonder if we can somehow work with UI team, docs team to address some of these problems? What are your thoughts on it?

        • ceo 1:27 pm on February 26, 2013 Permalink | Reply

          For the record, as a totally sighted user, I also had trouble with understanding the featured image feature in WordPress. In fact, there is a ticket to that very problem for which developers are creating a fix.

          I find it gets even more confusing because not all themes utilize featured images in the same manner. Some display them only on specific views while others display the image on all pages (post, archives, excerpt, etc.). Sometimes having a featured image and the same attached/inserted will show you a double image and other times not. This alone makes documenting what exactly a featured image is rather difficult since there’s no single treatment for what to expect depending on how the theme utilizes them.

          As to the links, that’s been brought up before (and I think there’s probably a ticket somewhere, though of course I can’t find one now). More descriptive links would be very beneficial given the sheer number of links present in the admin. And actually is somewhat part and parcel with the accessibility of the Media Panel, too, because when arrowing down you can move outside of the media window and not realize that what you are editing is actually back into your post or a link that will take you away from the edit screen entirely.

          • _Redd 1:32 pm on February 26, 2013 Permalink | Reply

            Great points, as always, ceo…

            …and I forgot totally about the theme issue……

            That said, I think this group, through its discussions, is in the process of nailing down the particulars and the details that developers need to develop accessible features. I’m sure learning a LOT just by being here. I’m betting the conversations here are the kernel to a next generation of WordPress that incorporates accessibility, not just add to it.

            Thank you (yet again) ceo

        • _Redd 2:01 pm on February 26, 2013 Permalink | Reply

          @graham @ esmi @ceo @joe and anyone else involved in the accessibility efforts, regarding Donna’s recommendation:

          The issue that has taken most of my time has to do with Media. My first suggestion for WP is to put together a concise Tutorial/Help topic addressing the definitions and description of the various types of images – header image, profile image, featured image, images inserted into posts and pages, attached and unattached images, permalink vs. File URL, the settings options for image size, which are editable, alternative options for uploading and inserting images and explainations of the difference between and the purpose of the file title, caption, alt tag and description

          I have to put together a tutorial for my workcenter on just these items. Let’s talk (maybe in IRC meeting) whether I could volunteer to help out with this, or coordinate on some level to assist. We could accomplish multiple tasks simultaneously; getting a tutorial out there, while incorporating accessibility issues.

          My only concerns would be my own competence (or lack of it), and whether or not I would be stepping on someone else’s territory. I absolutely rescind any request to do this if someone else is already working on it, or has plans to.

    • esmi 3:05 pm on February 26, 2013 Permalink | Reply

      A tutorial would be better handled by the Support group as it’s not really accessibility-specific. In fact, there might already be something available in the new User Guide.

    • _Redd 4:15 pm on February 27, 2013 Permalink | Reply

      Did you see the awesome ticket here?
      Hooray!

      3.6-Nav Menus Tracking Ticket

      It references ticket 14045 Give the menus page an accessibility mode option, like the widgets screen.

      Terrific, super! Appreciation for this!

    • Leslie Goldman 3:28 pm on March 4, 2013 Permalink | Reply

      I updated to the latest version. I cannot figure out how to resize my photos. I am up against a conference deadline. I had no problem the a previous version where I could designate what size photo I wanted. I am very stymied my work now. How to you edit the size of a photo for insertion into a post or pages?

      http://plantyourdream.net/?page_id=15535

  • esmi 12:29 pm on February 14, 2013 Permalink
    Tags: , links   

    Spawning New Windows/Tabs 

    Sorry for the flurry of posts but there’s an important discussion going on in re-opened Trac ticket #20839. The current discussion is focusing on:

    1. Should the “Visit plugin site” offsite link (in Plugins → Installed Plugins open in a new window/tab? (A no-brainer?)
    2. The best way to pre-warn users of an offsite link

    Some practical suggestions for the latter might come in very useful right now.

     

    • _Redd 1:07 pm on February 14, 2013 Permalink | Reply

      From a student use perspective, it seems that no matter WHAT I do to flag a link, students will simply use a “back button” on the browser. If they click on the link and it’s not something they want to see, they just hit a back button, not a bread crumb. Opening in a new window robs them of that back button functionality

      And, of course, I’m not saying its right or wrong, I’m just passing an observation when I ran tests with students. My carefully crafted links were ignored….

      As far as perhaps using icons to signal a way back home, I was stunned that the little “home” icon meant nothing to them….they just thought it was a decoration.

    • esmi 2:10 pm on February 14, 2013 Permalink | Reply

      Opening in a new window robs them of that back button functionality

      Exactly! And when you're a switch user, that means you're effectively left stranded in the new window. And the never-ending problem with trying to use conceptual icons is that not everyone "gets" the concept that you're trying to imply.

      • _Redd 2:12 pm on February 14, 2013 Permalink | Reply

        What is a “switch” user?

        • esmi 2:54 pm on February 14, 2013 Permalink | Reply

          Switch access. Think of it like a single button tab key. Used by people with severe mobility problems and can be operated by the hand, foot or elbow. Switch users often use onscreen keyboard software to carry out actual typing (eg completing a form) but, in all other areas of web surfing, can be considered as sighted keyboard navigators with access to just a TAB key.

          • _Redd 6:24 pm on February 14, 2013 Permalink | Reply

            Thank you, esmi!

    • GrahamArmfield 12:12 pm on February 15, 2013 Permalink | Reply

      @esmi my view is that links should ideally never open a new window, even on links that point to external sites – you should always give the user a choice.

      There are times however when that may break a transactional flow – eg creating a payment on an online banking site, and it may be desirable for a new window/tab to be opened.

      But how to warn users if a link poitns to external site and/or is going to open a new window?

      An icon with an appropriate alt attribute would work for screen reader users as long as it was part of the link. However, yours and @_Redd’s comments about people ignoring or not understanding visual icons is so true.

      I would not recommend using the title attribute – that is only guaranteed to work for mouse users, and the duplication of data is not always welcomed in screen readers that do voice title attributes – either by default or as a result of user settings.

      • esmi 12:32 pm on February 15, 2013 Permalink | Reply

        how to warn users if a link poitns to external site and/or is going to open a new window?

        Ideally, in clear text as part of the link text itself.

        yours and @_Redd’s comments about people ignoring or not understanding visual icons is so true.

        One possible way around this is to incorporate a warning message at the top pof the relevant page along the lines of “Please note that links in this page highlighted by [icon image] will open in a new window”.

        or as a result of user settings

        It’s long been my understanding that experienced JAWS users turn off its Verbose mode, so will not hear any title attributes. It could be argued that is their choice and that developers should not be responsible if they (the devs) are using correct & appropriate markup. But there’s no suh “get-out” when it comes to sighted keyboard navigators — such as switch or voice recognition users,

  • esmi 1:10 pm on February 7, 2013 Permalink
    Tags: , , , ,   

    IRC Meeting: 6 Feb 2013 

    Thanks to everyone who managed to make the IRC meeting on #wordpress-ui yesterday.  We had a very productive discussion and — despite the entertainment provided by way of my terrible iPad typing — took the first steps towards organising the group along more formal lines.

    @GrahamArmfield will be looking after Trac. Time permitting, he will be monitoring the existing accessibility-tagged tickets and taking the lead on the submission of new Trac tickets to cover issues such as the problems within the current custom menus admin area. So if you are thinking of raising a new Trac ticket, can you raise the subject here first? That way, we should avoid unnecessary replication.

    @joedolson expressed a vested interest in the editorial flow area but, for the time being, will be concentrating on front-end accessibility via the proposed theme accessibility audit and an extension to the current theme submission checks.

    @AccessibleJoe will take the lead on user testing videos so that we can build up a library of video resources to support core developers.

    @esmi will continue to take lead on documentation (liaising with @Siobhan and @DrewAPicture) as well as working with @lessbloat and other members of the UI team to try to develop in-house user accessibility testing.

    We are, however, still stretched pretty thin. So if you would like to get involved, we would love to hear from you. Those of you with the skills to create patches will be particularly welcomed by the UI Team who are currently overhauling the Custom Menus and Post Revision areas.

    #wordpress-ui log for February 6 2013

     

    • Nelson 1:30 pm on February 7, 2013 Permalink | Reply

      I’m sorry, I was out yesterday! I missed so much! I am so so glad to see this move forward, and I will coordinate to help however possible. I’ll be in touch. Thanks to all for the committment to accessiblity.

      • Redd (formerly Nelson) 1:53 pm on February 7, 2013 Permalink | Reply

        esmi, I am reading through the IRC Ui-channel chat entries from yesterday, trying to catch up. I found the following statement: esmi

        Does anyone else read the other core P2 blogs regularly?

        What are the P2 blogs? Are they the same thing as the IRC logs?

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

      Hi. I was hoping to stop by yesterday just to listen, but kept forgetting to go to time zone converter to figure out what time it was. I don’t think I have much to offer right now as I’m still learning a lot of the terms you’re using. But I’m grateful this group exists.

      >>So if you are thinking of raising a new Trac ticket, can you raise the subject here first?>>

      Since this seems to be a general request, would you mind explaining what it means, so I can try to comply?

      • ceo 4:04 pm on February 7, 2013 Permalink | Reply

        Trac is where bugs are reported and other changes to WordPress are, well, tracked. It can be intimidating for those unfamiliar with it, so if you are not comfortable submitting a bug we ask that you report things here. Also, we want to avoid duplicate tickets. (An example of an ongoing Trac right now, is the Custom Menu enhancements.)

        For reference: http://codex.wordpress.org/Reporting_Bugs

      • esmi 4:19 pm on February 7, 2013 Permalink | Reply

        We’d love to have your input at the meetings but if you can’t attend, there should always be the posted summaries the day after. Plus I’ll try to always include a direct link to the IRC logs for that day & channel so you can read the full discussion at your leisure.

    • Sveta 10:09 pm on February 7, 2013 Permalink | Reply

      “@AccessibleJoe will take the lead on user testing videos so that we can build up a library of video resources to support core developers.”

      Regarding videos, will they be accessible via captions? There are developers who are deaf. Thanks!

    • esmi 10:35 pm on February 7, 2013 Permalink | Reply

      Yes. We’ve already discussed this at some length both at the meeting yesterday and via email today. We will ensure that captioned versions of videos are widely available.

  • Graham Armfield 12:28 pm on February 6, 2013 Permalink
    Tags: , post formats,   

    Are Trac Tickets Still the Best Way to get Accessibility Improvements in WordPress? 

    Last year, as a result of a number of trac tickets raised by myself and others, a number of accessibility improvements were made to the WP admin screens in 3.5. This was a good thing in that it showed that some WP developers were happy to address the challenges with existing functionality. And for existing accessibility issues I suppose this is still the right vehicle.

    However, I’m troubled with this approach when I think about new functionality that is being developed within every release of WordPress. So far in 3.6 I’m seeing that there are going to be significant changes to the UIs for Custom Menus, Post Formats, and Post Revisions – and there may be others.

    It feels to me that there is a disconnect here. All these new and ‘improved’ features seem to get hammered out and developed without accessibility really being thought about. Using trac tickets here to raise accessibility issues seems like trying to bolt the stable door after the horse has departed.

    I think it would be a disaster if these new features are developed without some consideration for accessibility, and I’m sure we can all agree that it’s a lot more work to retrofit accessibility into developments. In fact sometimes it’s not really possible – when the design is so alien to accessibility.

    I’d hate to see Custom Menus, Post Formats, Post Revisions become the next accessibility disasters – like Theme Customizer, and the new Add Media Panel.

    Is there anything we can do to ensure that this doesn’t happen?

     

    • George Nilsen 12:51 pm on February 6, 2013 Permalink | Reply

      I’m with you. I just got it squared away with mine, and ‘if it ain’t broke, don’t fix it’!

    • ceo 1:07 pm on February 6, 2013 Permalink | Reply

      FWIW, Custom Menu screen has never really been entirely accessible.

      • lessbloat 2:21 pm on February 6, 2013 Permalink | Reply

        With that said, I’ve already committed to making it much more accessible this time around.

        • ceo 2:41 pm on February 6, 2013 Permalink | Reply

          Thanks, @lessbloat; I am very pleased to hear this. Yay!

    • andrea_r 1:57 pm on February 6, 2013 Permalink | Reply

      Since a lot fo these changes are now undergoing UI tests, what about speaking with the people doing so (usually @lessbloat) to have people with accessibility issues test the proposed changes as well?

      • esmi 7:08 pm on February 6, 2013 Permalink | Reply

        I’m in the process of putting together a team of volunteers for exactly this kind of purpose. Right now I have 3 (possibly 4) testing team members but it’s still heavily skewed towards users with visual impairments. So if anyone knows users who have dyslexia or are sighted keyboard navigators etc, please point them towards the volunteer form. We can never have too many volunteer testers.

        I had just started talking to @lessbloat about user testing when the flu intervened but I’m hoping we can start to offer some sort of formalised accessibility user testing asap.

        • lessbloat 7:15 pm on February 6, 2013 Permalink | Reply

          Happy to help where I can just ping me when you’re ready. :-)

    • Helen Hou-Sandi 2:20 pm on February 6, 2013 Permalink | Reply

      All these new and ‘improved’ features seem to get hammered out and developed without accessibility really being thought about.

      That is inaccurate, and to be frank, it is very frustrating to see that kind of false accusation, especially on one of the Make P2s. We have open office hours twice a week for every single one of these features, where anybody is welcome to join. I would especially welcome anybody who has expertise in an area where I don’t, and I would guess that any of the other feature leads would as well. Making things accessible is extremely important, but without expertise and actual help, I don’t see how it can get done. It is hard enough to just get the features working, and yes, polish often (or even usually) has to wait until it just works in the first place, or else you’re trying to make something accessible that won’t even make it into the final release because it’s incomplete. If you have a particular accessibility concern with the way something is currently progressing that hasn’t been caught, then please say so.

      As an example, in the case of post revisions, quite a few iterations have been tossed because they relied on colors alone. I mentioned accessibility as something that needs consideration in one of my last updates about post formats UI. I’ve seen quite a few comments from @lessbloat about the lack of accessibility on the menus screen and whether or not there is somebody out there who could tackle it. Nobody’s risen to the challenge of actually helping with accessibility, and of course just pointing out that we need to make something accessible doesn’t make it so.

      • GrahamArmfield 3:11 pm on February 6, 2013 Permalink | Reply

        Thanks for your reply Helen. I know that you and @lessbloat have mentioned accessibility and I’m glad that you both voice a commitment to improving the situation. My post was written from a position of frustration and I apologise if you or anyone else feels offended by it.

        Part of my frustration stems from the fact that I would love to help test and comment on the accessibility issues but my time available to spend in here and the various other forums is very limited at the moment. I understand that that is not your issue but mine to deal with.

        Although I have some development knowledge I certainly don’t feel I have enough ability to contribute on the coding front directly – but I can advise on accessible markup if posed specific questions.

        Re the office hours thing – I could potentially take part in some of those. I gather from Esmi that they are done via IRC, but are there any specific WP connection instructions available anywhere for those who’ve not used IRC before?

        One of my aims in posing the question in the first place was ‘How can we ensure that accessibility is more embedded in the WP design and development process in the future?’

      • esmi 3:47 pm on February 6, 2013 Permalink | Reply

        We have open office hours twice a week for every single one of these features, where anybody is welcome to join

        Where and when? Since we’re hoping to set up our own IRC meetup shortly, we could perhaps liase with the UI developers on a semi-regular basis through at least 1 nominated person to look at what needs doing, what needs testing and what, if any, code we could contribute.

        whether or not there is somebody out there who could tackle it

        I have to admit that my js-fu is pretty dire – otherwise I would have volunteered. I’ll ask around and see if I can blackmail persuade someone with the right skills to get involved with this specifically.

        • Aaron Jorbin 5:16 pm on February 6, 2013 Permalink | Reply

          All the office hours are listed in the sidebar at https://make.wordpress.org/core/ under the Version 3.6 Teams header and they all take place in #wordpress-dev on freenode.

          • esmi 7:19 pm on February 6, 2013 Permalink | Reply

            So would this mean we can hassle @Dave Martin and @DrewAPicture about custom menus? ;) I know Drew from #wordpress-sfd.

    • Joe Dolson 3:42 pm on February 6, 2013 Permalink | Reply

      Helen’s comment was very apropos to how accessibility can become more embedded in the dev process in the future: somebody with accessibility expertise needs to become directly involved in the core development process. But we continue to be a small community, and we have to do what we have time for — and that means accepting that what we do may end up being a patch, if that’s what we have time for.

      I’ve been focusing on front-end accessibility issues, but that doesn’t leave me a lot of time for participating on back-end issues; but the problem is in no way a lack of core commitment to the idea; it’s a lack of expertise getting involved in the process.

      In fact, as I see it, the weakest part of the Make WordPress Accessible group is coordination and cooperation — we could be much more effective if we discussed our goals and set specific people to working on specific tasks. Right now, I feel somewhat overwhelmed all the time, because I feel like I’m always trying to look at the whole picture of WordPress — and it’s huge! None of us have time to address every issue. If we coordinated, we could each take lead on working with one section, and then we’d be able to move forward in a much more efficient way.

      • esmi 3:50 pm on February 6, 2013 Permalink | Reply

        Well said! And, I think, something that should be the main point of the first IRC meetup.

        • ceo 3:52 pm on February 6, 2013 Permalink | Reply

          Do we have a date/time yet for the IRC meetup? Or, actually, where it is going to be?

    • Jen Mylo 4:40 pm on February 6, 2013 Permalink | Reply

      To influence core development, get involved with core development. That’s what it all comes down to. This group (accessibility) is an interest/skills group, not a group responsible for a product like the core team, support team, theme review team, etc. We’re discussing how to differentiate groups like this, but even when that happens, these shared interest/skill groups will still need to get involved with the responsible product teams’ workflows in order to have influence on their products.

      When we asked Esmi to act as the rep for this group to the core team back in the day, that was the intent… that she would bring accessibility volunteer concerns/suggestions to the core team regularly and act as a liaison. If Esmi can’t make the core team chats, someone else can offer to do so. And Trac tickets are still the most effective way to ensure that something is on record as needing to be fixed, where everyone can see it (since irc logs often don’t get reviewed by people who miss meetings). But ultimately, wherever this group wants to affect the project, be it core, plugins, the wordpress.org site, etc, it will need to work directly with the groups responsible for the things in question.

      • esmi 7:25 pm on February 6, 2013 Permalink | Reply

        Agreed but trying to monitor all of the other groups is like trying to herd cats, IME. As Joe said above, the potential remit is so big that trying to keep up with everything — let alone contribute in a meaningful way — is somewhat overwhelming. Is there any possibility of flipping this over and, instead of us trying to get involved at the relevant points, someone from the other groups posting here asking for help/input/whatever? It would take a huge burden off this group trying to watch everything at once.

        • mrwweb 2:30 pm on February 8, 2013 Permalink | Reply

          +1 @esmi.

          If the burden is on the Accessibility team to get involved, that implies that accessibility will only be considered when someone raises the issue of accessibility. I think (hope?) everyone agrees that ALL of WordPress should be accessible. So I think the basic question of this post is how to make accessibility a universal consideration of all teams from the start. Clearly some teams are doing this already, but the burden still seems placed on this team which inevitably means that somewhere features are being developed start-to-finish with possibly no consideration for access.

  • 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 12:24 pm on January 9, 2013 Permalink
    Tags:   

    Stumbled across the Accessibility Widget plugin last night which looks very interesting. I intend to test it out as soon as I have some free time but has anyone else used it on a live site? I was thinking that we could have a page here listing similar useful plugins and tools.

     

    • Rian Rietveld 1:14 pm on January 9, 2013 Permalink | Reply

      Thanks for the tip @esmi

    • GrahamArmfield 1:48 pm on January 10, 2013 Permalink | Reply

      Hadn’t seen that one before but will have a look. There is also wp-chgfontsize which I have used on a couple of sites in the past but hasn’t been updated for a while now.

  • Andrew Ozz 12:42 am on July 24, 2012 Permalink  

    @esmi the tabindex attributes are still needed on the toolbar as the HTML for it is outputted at the bottom but it’s shown at the top of the screen. All other tabindex have been removed making “tabbing” flow much better.

     

    • esmi 8:33 pm on July 25, 2012 Permalink | Reply

      The problem with tabindexes is that they remove choice. I appreciate that the markup is at odds with the visuals but those who can see & use a mouse still have a choice as to where to go next. Tabindex takes that choice away from the keyboard navigators.

      What about using “jump-to” links instead? Preferably hidden offscreen at the top of the markup but revealed on active/focus? That would be way cooler and offers choice.

      • Andrew Ozz 10:12 pm on July 25, 2012 Permalink | Reply

        Sure, can do that. There is already a “Skip to content” link that moves the focus to the main content area on all admin pages, bypassing both the toolbar and the menu.

        Thinking we can add a similar link that would focus the toolbar’s container. It will have to be part of the toolbar code so it’s outputted on the front-end too and will have to have tabindex set as it will be near the bottom of the HTML source, but there will be no need for other tabindex attributes in the toolbar.

        • esmi 11:48 am on July 26, 2012 Permalink | Reply

          I’ve been playing with the admin bar, I removed all tabindexes (including the one in the admin bar search) and inserted a link immediately after the #wpadminbar div that pointed to #wibble.This was the only link with a tab index (1 , in this case).

          I then added the wibble id to the quicklinks div. The resulting markup allows keyboard navigators to either proceed to the admin bar (by pressing Enter or similar) or, by just moving on, go go straight to body of the page. That works really nicely and keeps the whole thing self-contained for use on the front or back end. Thoughts?

          • Andrew Ozz 9:36 pm on July 26, 2012 Permalink | Reply

            Yes, that’s exactly what I meant. Lets put that in.

            With this we will have two skip links at the top of each screen in the admin: Skip to content and Skip to toolbar. Perhaps both links can have the same tabindex value, maybe 5 or 10, so that they are accessed first on the screens. All other tabindexes are/will be removed.

          • Andrew Ozz 6:47 pm on August 5, 2012 Permalink | Reply

            Added this in [21423]. The trac ticket is at: http://core.trac.wordpress.org/ticket/21471

        • Cyndy Otty 12:47 pm on July 26, 2012 Permalink | Reply

          As a screen reader user, I could almost cry with joy to see this fairly simple addition of a skip link made. :-)

    • Bim Egan 4:04 pm on July 30, 2012 Permalink | Reply

      Cyndy, as a fellow screen reader user I was sad to think that you may not get what you hope for out of the proposed skip links. This is because the skip links themselves will need a tabindex value to move them to the top in tab order, because they are actually at the end of the page. Tabindex rarely works for screen reader users because the screen reader is working with a buffered copy of a page, not the page itself. So the skip links may not help you. Do you also use headings for navigation? Most screen reader users find these a lot more useful and reliable. Just press the letter “H” and see if your screen reader supports heading navigation.

      • esmi 9:26 am on July 31, 2012 Permalink | Reply

        If you re-read Ozz’s response, you’ll see that there will be a skip link at the top of the page in the Admin area that will allow people to jump straight to the Admin bar.

← Older posts

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