Make WordPress Accessible

Updates from Graham Armfield Toggle Comment Threads | Keyboard Shortcuts

  • Graham Armfield 10:31 am on April 4, 2013 Permalink
    Tags: , , , , , ,   

    Accessibility IRC Chat – 3rd April 2013 

    A few of us took part in the IRC chat yesterday (see transcript here). Not surprisingly the main subject was the Add Media Panel accessibility, and the format of the chat turned into a live screen reader test on the functionality performed by @_Redd and @arush (and myself).

    @lessbloat had kindly had a go at implementing my quick and dirty pragmatic ARIA solution – for which we are truly grateful. Once we’d got access to an environment where the changes were in effect we could see that vast improvements had been made to the accessibility.

    I’ll save the detail to the blog post about Add Media Panel but to summarise:

    • Keyboard-only users can now tab through the items in the media list and select/deselect using Enter key
    • Screen reader users were getting some useful information but possibly only the newest versions can fully use this functionality.
    • Voice recognition users can at least use the tab commands to move around the list and select them.

    The key decision now is whether the functionality is useful and solid enough to include in 3.6. A couple of extra enhancements would make the solution better for screen reader users – once again see previous post.

    My vote would be to run with it if we can get the small further enhancements. We can hopefully address the rest of the accessibility issues within 3.7.  But what do you think?

     

    • _Redd 11:39 am on April 4, 2013 Permalink | Reply

      RUN WITH IT! Enhancements are for plugins!!!

    • Joe Dolson 3:23 pm on April 4, 2013 Permalink | Reply

      This is great Graham. I’d agree with _Redd – this sounds like a great improvement. I don’t see any reason to wait for perfection; this is an important step forward.

    • _Redd 2:29 pm on April 5, 2013 Permalink | Reply

      I have the 3.6 beta up, and, as one who is ignorant of screen readers, I can at least say that my version of NVDA announces itself nicely in the Add Media area. Thank you, Graham and lessbloat, this is a jaw-dropping leap forward! :-)

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

      Great work Graham – many thanks!

    • GrahamArmfield 1:31 am on April 3, 2013 Permalink | 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 | 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 | 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 | 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 | 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 | 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 | 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!

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

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

      • Andrew Ozz 10:56 pm on March 18, 2013 Permalink | 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 | 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 | 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.

  • 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

  • Graham Armfield 5:47 pm on February 15, 2013 Permalink  

    Creating Custom Menus 

    There is a lot of discussion and design going on at present concerning the changes that are being made to the Custom Menu Builder for WordPress 3.6. These discussions can be followed via trac ticket #23119.

    But as part of that work the Custom Menu Builder needs to become easily accessible to those who can’t use a mouse, or who are using screen readers or speech recognition software.

    During our IRC sessions this week and last we touched on potential solutions. So far the solutions have boiled down to:

    1. Use a separate accessible version in a similar way to how the accessible widgets functionality works.
    2. Ensure that the rebuilt functionality, which will almost certainly feature drag and drop contains and generates enough information to allow easy manipulation by those using assistive technology.
    3. Ensure that the markup of the solution externalises enough information about hierarchy and makes influencing it easy.

    But we need some more input on how this functionality could be deployed accessibly.

    Although the widgets method is usable, could it be better? If so, how.

    Could a drag and drop solution with ARIA help really work for blind users?

    Please feel free to comment with any ideas you may have.

     

    • Joseph Karr O'Connor 6:03 pm on February 15, 2013 Permalink | Reply

      Not all SR users navigate by ARIA routines, especially less experienced users or those who have not upgraded their SR. I believe a separate accessible version is the way to handle this.

    • Jacek Zadrożny 12:32 pm on February 16, 2013 Permalink | Reply

      I think that the best way is similar to putting widgets. Small form with name, priority and so on.

    • _Redd 3:07 pm on February 18, 2013 Permalink | Reply

      I am speaking out of ignorance here, so please accept my humiliation in advance if this idea has no possibility of working.

      It is possible to re-order pages in WordPress. We can do it by hierarchy, which involves a drop-down option, which as I understand it creates all kinds of problems for AT. But we can also re-order the pages order by simply typing in a number in a field. Is it possible to somehow exploit the code that changes the order of the pages, and apply it to re-ordering the items on a menu? We could \”focus\” the menu item in the same way that we could \”focus\” the page order.

      (Specifically, in the Page Attributes section, I\’m referring to the \”Order\” option)

      Am I making sense?

      • _Redd 3:30 pm on February 18, 2013 Permalink | Reply

        Small form with name, priority and so on

        Which, when I think about it, is what Jacek is saying, isn\’t it?

        Sorry, Jacek, realizations happen to me slowly……..I\’m having one of my Doh! moments…. :-)

      • GrahamArmfield 5:42 pm on February 27, 2013 Permalink | Reply

        Have thought about this a bit more and done some investigation in how the Custom Menu items are stored etc.

        I think that the two key bits of hierarchical information that people need to manipulate for each item would be:

        The parent item for this item – could be none of course
        The menu order (which would only come into play against sibling menu items?)

        It’s a bit like setting hierarchy for pages in the old way – Who is my parent? What is my order number?

        So an accessible option would need to incorporate a dropdown and a text box for each item – alongside the other extra data stored – classes etc.

        • ceo 6:42 pm on February 27, 2013 Permalink | Reply

          You mean this, @grahamarmfield?

          With the use of custom menus, it’s basically a depreciated feature, but it’s still available as a setting within Page Attributes. (Those settings were how I had my navigation menu built in an older theme as it used the data for pages.)

          EDIT: Whoops. Helps if I write the HTML properly.

          • GrahamArmfield 6:54 pm on February 27, 2013 Permalink | Reply

            Yes, exactly that Cyndy. I still have a couple of sites that rely on wp_list_pages.

            I’ve been looking into the menu object and what gets stored about each menu item as I’ve been working on a plugin.

            It’s fairly easy to retrieve a list of items in a custom menu.

        • _Redd 6:53 pm on February 27, 2013 Permalink | Reply

          @GrahamArmfield, I’m not clear as to why a dropdown is needed (speaking as a very, very ignorant person here)

          Isn’t there some way of entering a number in a field, and then just set up an “order_by” function?

          Honestly, I’ve been thinking of hijacking one of the menu attributes in the menus screen, the field that says, “Title Attribute” and trying to convert it to a field by which users could enter numbers. From that point, maybe it could just be a matter of displaying the hijacked “Title Attribute” as a re-purposed field by which to enter a number, and then have an “order_by” ASC or DESC

          Am I making sense?

          I would ask if I’m crazy but I already know the answer to that one…..:-)

          • GrahamArmfield 6:56 pm on February 27, 2013 Permalink | Reply

            I might have misunderstood the menu order setting but I think we’d need users to specify a parent for a menu item as well as the order once they’d pull items across from the pages, posts etc boxes. On it’s own the menu order won’t do that – will it?

            • _Redd 6:57 pm on February 27, 2013 Permalink

              I don’t know….I’m pretty sure I’ve done it with at least a “no parent” setting, which I guess parent = 0, and re-ordered pages that way. No dropdown or reparenting involved. Let me check right now on one of my sites.

            • GrahamArmfield 6:59 pm on February 27, 2013 Permalink

              But if I want to set something as a parent for a menu item, how would I do that from the menu order alone. That doesn’t convey the hierarchy, that menu_parent_id does I think.

            • _Redd 7:00 pm on February 27, 2013 Permalink

              Just tried it, works without setting a parent. I’ll try and get a screenshot

            • _Redd 7:03 pm on February 27, 2013 Permalink

              Graham, I may be misunderstanding what you’re talking about, and I know that your knowledge of HTML far outweighs mine, so let me revisit.

              I consider the parent the menu itself….if we have a home menu, then that is the “parent” item–”home”. If we have a “dog” menu, then we have a “parent” item in “dog” Beyond that, I’m not seeing a need for any additional parents.

              I hope I’m making sense……

              Let me get a screen shot or two

            • _Redd 7:04 pm on February 27, 2013 Permalink

              Just tried it, works without setting a parent. I’ll try and get a screenshot

              And in this case, I specifically meant for pages…be right back

            • ceo 7:11 pm on February 27, 2013 Permalink

              Wouldn’t the parent specify if the menu item was “nested” under (i.e., creating a sub-menu)? At least, that’s how it works with the Page Attribute. I don’t think simply ordering the item would accomplish this, and currently the only way to do this now is via drag-and-drop.

            • GrahamArmfield 7:23 pm on February 27, 2013 Permalink

              _Redd, I was talking about influencing the hierarchy of items within a given menu – typically pages I would guess.

              If I add five pages to an empty menu – a, b, c, d, e their menu order might be:

              a 1
              b 2
              c 3
              d 4
              e 5

              But if I want pages b and c to be sub-pages of a, I think that their stored menu order would be identical. There isn’t enough to describe the hierarchy.

            • GrahamArmfield 7:26 pm on February 27, 2013 Permalink

              Cyndy (ceo) is right I believe, the hierarchy or nesting is defined by the menu_parent value.

            • _Redd 7:36 pm on February 27, 2013 Permalink

              @GrahamArmfield, @Cyndy, I unfortunately do not know enough about the subject at the moment.–that said, the code for reorganizing items exists in the page functions. We should be able to hijack that code.

              Here’s a sample of what I am trying to describe link to screenshots showing pages re-ordered non-hierarchal

              No drag-and-drop is needed to re-order the pages.

              Can’t we exploit that code somehow?

            • _Redd 7:37 pm on February 27, 2013 Permalink

            • ceo 7:47 pm on February 27, 2013 Permalink

              @reddhound – but the ordering itself is not the only option within the menu screen. Nesting/sub-menus also need to be accounted for, thus the “parent” suggestion. See: http://guidingdolly.com/nested-menu.png

              This is what I meant when I was referencing the drag-and-drop above.

            • _Redd 7:49 pm on February 27, 2013 Permalink

              @Cyndy @ Graham you have given much to chew on, and my head is spinning. I’ll put aside for now, keeping your comments in mind, and will certainly revisit.

              Thank you BOTH, and will “talk” to you soon!

              Take care

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

      Did you see ticket 23607?

      this awesome ticket 23607 is referencing a task to Give the menus page an accessibility mode (like widgets), based on ticket 14045

      This is Terrific!!

  • Graham Armfield 5:08 pm on February 13, 2013 Permalink
    Tags: , , ,   

    WordPress Accessibility Trac Tickets Update – 13 Feb 2013 

    This is a useful link that returns all the accessibility-related trac tickets.

    Existing Trac Tickets (Bugs) that aren’t Fixed.

    12825 – Text resizing in Firefox – Raised 3 years ago(!) this one talks about the fact that WP admin screens don’t always look very clever when text is resized by user. Whilst most areas are OK, the buttons and toolbar at the top of the page are fixed-height and so text-spillage occurs. I don’t think everyone realises that zooming and resizing text are not the same thing and suit different people.

    20294 – User password field missing label – Looks like some work was done for 3.5 but it appears it was never implemented.

    21289 – Custom Menu builder – Raised last year but turned out to be duplicate of 14045 and linked to 22485. Ticket 23119 (see also below) is covering the rework of Custom Menus and design is still being debated hotly. Need to keep eye on this one as Custom Menu Builder has never been accessible since first introduced.

    21334 – Accessibility of Quick Edit Panel – Raised last summer, and is getting some attention now. Have suggested (amongst other things) that quick edit panel might be always visible as a result of switch in Screen Options, but kind of nervous about that. Could do with some further accessibility input (ie not just mine). The issue about whether certain links should be permanently visible coming in here as well – cf Skip links at top of page.

    22104 – High contrast admin colour scheme – Raised in the autumn, and some debate ensued. However nothing really happened about this. Do we want to get behind this? Is there one high-vis theme that would work for all?

    22606 – Keyboard issues selecting a background image in Theme Customizer – Seems there is a fix for this, but need to test.

    22682 – More keyboard issues with Theme Customizer after page refresh – Some action but has been downgraded in importance just before Christmas.

    22933 and 23195 – Keyboard tab order in edit screens – Fix is now available that makes tabbing more consistent allegedly. But I haven’t been able to test this.

    Trac tickets covering UI work

    23119 – UX improvements to nav-menus.php – A LONG ticket with much debate. Difficult to work out exactly what is being proposed for accessibility here. One ticket proposed that accessibility option like widgets should be included – and apparently the stubs for that code are actually in the menu builder and may be used if js not available. Cyndy pointed out within ticket that drag and drop, and even using arrow keys to move items is not really any good for blind people. But would that be an option if there was sufficient announcing (using ARIA live regions?) to allow context to be voiced? And is it OK to just use the arrow keys for this – when users might expect something different to happen? And what about users on tablets using AT like VoiceOver?

    New tickets required?

    Add Media Functionality – don’t believe this is keyboard accessible (inc screen readers), nor easily accessible by speech recognition software either. But haven’t had chance to test yet.

     

    • ceo 6:31 pm on February 13, 2013 Permalink | Reply

      I’m reserving further comment on the Menus until I can test it because while in theory I don’t think it can work with the keyboard, I’m open to trying it out to confirm. Also, that ticket is just ridiculously long.

      Add Media Functionality – don’t believe this is keyboard accessible (inc screen readers), nor easily accessible by speech recognition software either. But haven’t had chance to test yet.

      The big stumbler I’ve run into with this is if you are trying to insert previously uploaded media. I don’t know if it’s actually impossible to select a file, but there’s no indication it HAS been selected that I’ve determined so I can’t say for certain one way or the other.

      I’m sure there’s probably other things, but I’m currently having a memory block.

    • toscho 7:55 pm on February 13, 2013 Permalink | Reply

      20839 – “Visit plugin site” should open in a new window needs a look from the accessibility perspective too.

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

      Already on it. :)

    • esmi 3:23 pm on February 18, 2013 Permalink | Reply

      New tickets required?

      The default output of comment_form() isn\’t ideal. It generates text inside plain paragraph tags within the <form></form> — which means that it could take two passes using JAWS (once in Forms mode and again using Virtual Cursor) to render all of the text. Ideally, the current plain text should be explicitely associated with an existing form conmtrol using the label attribute. It\’s possible to fix this in a theme but we really shouildn\’t be asking theme authors to jump through hoops to correct issues in core.

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

  • Graham Armfield 9:46 am on January 11, 2013 Permalink
    Tags: , usability,   

    User Videos – An Accessibility Angle 

    Over the last few months WP dev lessbloat has done a series of videos where he has invited in ‘real-life’ users to try out various features of the WordPress backend – and has videoed the experience.

    I’ve watched many of these videos and read the transcripts of the interactions and they are a really great insight into usability, and assumptions that developers make about how much users understand about what’s expected of them. The most recent one is at: http://make.wordpress.org/ui/2013/01/09/two-more-menus-user-tests-focusing-on-this/

    I’ve often thought that it would be quite revealing if somehow we could produce a series of videos of blind and motor impaired users trying out key bits of the admin area. These would highlight the accessibility issues perhaps more than words on a page could, and could constitute a powerful benchmark on which to base future improvements.

    Does anyone else think this might be useful? And if so, how could we go about making some?

     

    • Joseph Karr O'Connor 10:31 am on January 11, 2013 Permalink | Reply

      User testing is a powerful tool and can be very revealing.

      When the users being tested are local, for this type of usability testing I use Silverback by Clearleft Limited. It captures screen actions and embeds a video of the user in the frame. The user is captured by the built-in camera in the computer. Silverback is for Mac. http://silverbackapp.com

      This is not the only scenario. Remote user testing is also available. Here is an article listing some of the companies that do this: http://www.actualinsights.com/2012/free-remote-user-testing/

      Finally, asking for free participation in such studies is a sensitive issue in the disability community.

      The CSUN conference is coming up soon. I will devise some tests – I will take input from this group about the focus of those tests. I will put out a call for people to meet with me at the conference to do some testing. I will capture the experience with Silverback. I would like to offer something to participants – a Starbucks card for example – is there any budget for this?

      • GrahamArmfield 10:51 am on January 11, 2013 Permalink | Reply

        Thanks for your reply Joe.

        I’ve also seen some very useful accessibility tests of some websites that were done via sharing the screens over Skype and recording the results via Camtasia studio. Perhaps not as sophisticated but valuable nevertheless.

        The issue about budget is a good one. I’m not close enough in to the WP organisation to know about that – Esmi may have to comment on that. It would be interesting to find out if lessbloat gets a budget for his vids and gives his paricipants anything.

        Your idea about CSUN is a good one. For my money the focus should definitely be on things that are obviously not accessible – like Custom Menu Builder, etc. But it would be good to test the whole process of adding a new post with some media and some links and headings within the page. After all, that’s the key functionality that needs to work for everyone. Itwould also be nice to test things where the situation has improved recently after the tickets that got included within 3.5.

        Another issue is how widely these videos are publicised if they ever get made. My natural gut feel is that full public airing is good – for knowledge, and as a spur to improve. But I know that perhaps not everyone might agree with that.

        • Joseph Karr O'Connor 2:36 am on January 12, 2013 Permalink | Reply

          I’ll post the videos on YouTube and promote them to the accessibility and WordPress communities. I can’t do this alone. I will commit to getting people to engage in some focused testing. I cannot afford the time to CC the videos and provide audio description, which the videos will need. We’ll need someone to do that.

          • GrahamArmfield 8:06 am on January 13, 2013 Permalink | Reply

            I’m willing to help with this Joseph.

            Creating captions is not necessarily difficult but can be time consuming. But I’ve done some recent experiments and the facility within YouTube to create a captions file from a transcript actually works really well most times. Now it’s a lot easier to crowdsource the production of a transcript for a video than a caption file directly.

            With transcripts, you or I can upload into YouTube to use as the raw material for a caption. It’s then possible to hack the YouTube caption file where the auto-syncing hasn’t worked so well.

            So a possible workflow for each video would be:

            1. Shoot and edit video, and upload to YouTube.
            2. When someone has created a transcript we upload that to YouTube and go with the transcript-fed captions.
            3. Where necessary, people identify segments where the captions aren’t synching right and one of us tweaks as required.

            By the way, you’ll not be surprised to hear that the auto-captioning facility within YouTube is laughably bad.

            Do you need to create a WordPress Accessibility YouTube account? Is that the best idea? What does everyone else think?

            • Joseph Karr O'Connor 7:43 am on January 14, 2013 Permalink

              I believe we should start a WordPress Accessibility channel on YouTube only if we expect to regularly post to it. Otherwise, if I do a few user testing videos I can just post to my own channel.

            • Joseph Karr O'Connor 7:46 am on January 14, 2013 Permalink

              Thanks Graham, I’ve captioned lots of videos and know how time consuming it can be.

      • esmi 11:54 am on January 11, 2013 Permalink | Reply

        As far as I am aware there are no budgets available to anyone via wordpress.org. Where people do have access to user testing & video facilities, I would imagine that they are being provided as a form of sponsorship via their employers.

        • Joseph Karr O'Connor 2:19 am on January 12, 2013 Permalink | Reply

          Will WordPress have a presence at the CSUN conference? I will see if people will attend a WP Accessibility group Tweetup.

        • GrahamArmfield 8:08 am on January 13, 2013 Permalink | Reply

          Esmi, do you know lessbloat? Can you ask him how he goes about it, and whether he’d be up for doing any with user with disabilities? I’ve suggested it at least once in my comments on his posts but not had any response from him.

    • esmi 11:50 am on January 11, 2013 Permalink | Reply

      I think this would be an excellent idea and is very much in line with my hopes of building up a pan-disability panel of users within this group.

    • Nelson 12:45 pm on January 11, 2013 Permalink | Reply

      Joseph, that website you provided on actualinsights.com is great. I see that they have an app for iPads and iPhones–which to me, is huge. I had been looking a LONG time for something like this…..THANK YOU.

      http://www.actualinsights.com/2012/ux-recorder-screen-recording-app-for-ipad-iphone/

    • Sveta 9:20 pm on January 11, 2013 Permalink | Reply

      It is also important that videos are captioned and transcribed for those who cannot hear. None of WordPress.tv videos are captioned at all – to say nothing about many other online videos on other websites.

      • Cyndy Otty 5:05 pm on January 12, 2013 Permalink | Reply

        I don’t believe WordPress.tv has the ability as yet to transcribe videos. Though, even a separate text document/page/whatever would be beneficial in lieu of an actual transcription until something changes. Even something as simple as a detailed description of the video could be helpful.

        • Joseph Karr O'Connor 2:33 am on January 13, 2013 Permalink | Reply

          WCAG and Section 508 both require that video be captioned. Transcripts may be posted as a stop-gap measure until the video is captioned. Detailed description does not meet the criteria for success. Captioning services can deliver finished captioning quickly and economically when organizations don’t have the labor to do the job.

          The larger question for us all is: do we want to include all users, or do we find it acceptable that some are excluded?

          • GrahamArmfield 8:19 am on January 13, 2013 Permalink | Reply

            Good question Joe. My view is that we should aim to include all users, but understanding that that is not always possible – certainly initially.

            You’ll see my comments elsewhere about the provision of captions and how that could work. Cyndy’s point about wordpress.tv and captions is important. Captions isn’t the only accessibility issue with wordpress.tv.

            I think signed versions might be something that might be hard to deliver on a limited budget, and I’m not sure about adding audio descriptions.

        • GrahamArmfield 7:50 am on January 13, 2013 Permalink | Reply

          wordpress.tv has many problems with accessibility – eg lack of captions, and poor keyboard accessibility. It really needs to change.

          If WordPress wants to host the videos themselves then they need to embed them with a player that is keyboard accessible and supports captions.

          I’ve done a bit of work using the player that is available from Nomensa (http://www.nomensa.com/about/news-items/nomensas-accessible-media-player-20-now-free-download) which is pretty good for accessibility (keyboard control, captions) but with some limitations.

          I’ve created a crude WP plugin that incorporates it which I’ve used on a couple of sites. It’s not on general release as it’s nowhere near finished. But it works with videos hosted on YouTube.

          The biggest limitation of the Nomensa player at the moment is that for YouTube vids the player always uses flash which means that it’s not natively available on iPads and iPhones. However, if you’re hosting the vids yourself it can allegedly pull in the JWPlayer which allows delivery using the HTML5 video object on browsers that support it – should include iOS devices.

          Maybe consideration of the accessibility of wordpress.tv needs another thread – it’s a big subject.

    • esmi 1:51 pm on January 14, 2013 Permalink | Reply

      Maybe consideration of the accessibility of wordpress.tv needs another thread

      Agreed – as that might be edging to wards the edge of our remit. One area that is definitely within our remit is to review all videos used in support documentation – such as those being incorporated into the new User Handbook.

    • esmi 1:53 pm on January 14, 2013 Permalink | Reply

      do you know lessbloat?

      Not spoken to him myself but I will try contacting him for details.

      • esmi 4:19 pm on January 23, 2013 Permalink | Reply

        Update: Had a quick chat with lessbloat. He’s using usertesting.com and, as he works for Automattic, they are kindly picking up the tab for the tests. Had a quick look at the pricing structure for usertesting.com and it would work out pretty expensive if you wanted to carry out more than a couple of testing sessions.

  • Graham Armfield 12:07 pm on January 9, 2013 Permalink
    Tags: ,   

    3.5 Media Manager Accessibility 

    Has anyone had a chance to test the accessibility of the new Media Manager that came in with 3.5? I’ve not had time yet, but I am worried that it’s not fully keyboard accessible.

     

    • esmi 12:20 pm on January 9, 2013 Permalink | Reply

      I’ve run a quick test and it’s not too bad. The big issue in my tests was that I kept losing sight of the current focus, so better focus highlighting is definitely needed.

      The big grey area for me was at the point when I brought up the browse window to select the file I wanted to upload. I wasn’t sure how to select the file I wanted using keyboard alone. That’s really more of a problem with my experience than the interface but it did raise an interesting thought – where does WP’s remit stop when using standard operations like browsing your own machine? I don’t want to de-rail any discussion of the new Media Manager but I think we do have to keep in mind that there are points when an applications responsibility ends and the user has to take responsibility for learning how to use their own software. In my experience, it’s a point that can sometimes be overlooked in the (admirable) enthusiasm to make web applications as accessible as possible.

      • GrahamArmfield 12:34 pm on January 9, 2013 Permalink | Reply

        I think you are right Esmi, there is definitely a boundary between WP screens and functions and operating system screens and functions. And WordPress cannot be responsible for the operating system bit – we have to trust that people can learn to use the appropriate functionality of their machines. I know that doesn’t always happen but it’s outside of our scope.

        I just had another quick look at the Media Manager panel. I think tabbing goes ok as far as the search box, but after that I believe it actually goes back to links on the underlying post/page edit screen. But I’m not certain about that.

        • esmi 12:59 pm on January 9, 2013 Permalink | Reply

          I believe it actually goes back to links on the underlying post/page edit screen

          I had a similar issue and thought I’d make a mistake. I’ll take another crack at it as soon as I can.

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