WordPress.org

Make WordPress Accessible

Updates from April, 2013 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 | Log in to Reply

      RUN WITH IT! Enhancements are for plugins!!!

    • Joe Dolson 3:23 pm on April 4, 2013 Permalink | Log in to 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 | Log in to 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 | Log in to Reply

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

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

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

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

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

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

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

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

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

      Great work Graham – many thanks!

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

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

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

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

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

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

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

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

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

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

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

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

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

            Test Site

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

            Looks like I set up the hyperlink wrong

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

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

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

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

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

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

              Coming your way, standby

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

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

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

              OK I’m in. Will test shortly.

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

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

              I’m watching for your response with baited breath!

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

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

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

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

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

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

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

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

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

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

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

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

        What is a “switch” user?

        • esmi 2:54 pm on February 14, 2013 Permalink | Log in to 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.

    • GrahamArmfield 12:12 pm on February 15, 2013 Permalink | Log in to 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 | Log in to 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 12:19 pm on February 14, 2013 Permalink
    Tags: ,   

    Post Revisons Update 

    I managed to drop into the Core IRC meeting yesterday and was told that the our recent feedback on the new concepts for post revisions was very helpful. New screenshot mockups have now been created to incorporate fixes for the issues that we raised.

    Coding on the new post revisions may begin shortly, so let’s keep an eye on the outstanding tickets and new developments. In the meantime, thank you to everyone who took part in the post revision discussion and let’s keep up the good work.

    We can make a difference! :)

     

    • _Redd 12:54 pm on February 14, 2013 Permalink | Log in to Reply

      That latest mockup is AWESOME!!! It removes ambiguity in so many ways, and, it is easy to digest, cognitively speaking! Woo woo!

      • tady 4:55 pm on February 14, 2013 Permalink | Log in to Reply

        I know it’s just a mock up, but as a fully able person, I actually find the text behind the delete hard to read now. Will this render similar to the example you created above Esmi? If this is the case, then my point is moot and it’s just a symptom of the wireframing tool.

        • _Redd 6:15 pm on February 14, 2013 Permalink | Log in to Reply

          @tady, I sure understand why you find the text behind the delete hard to understand, but you may want to keep in mind that deleting whole paragraphs is not necessarily typical when editing documents. In one of my former jobs, I was basically a document editor, and I had to share those edits with others located at remote points of the globe. The edits would typically be by word or by sentence, not by whole paragraphs, and that strikeout feature (used in Word documents) came in extremely handy for finding edited areas fast.

        • _Redd 6:27 pm on February 14, 2013 Permalink | Log in to Reply

          @tady Although, that may bring up a point for consideration–is the intent to COMPARE versions (no need for deletion marks) or to REVISE versions (deletion marks are expected)–that may make a difference in how the text is emphasized.

          And again, thank you, thank you, thank you, for everything you are doing!

          • tady 8:11 pm on February 14, 2013 Permalink | Log in to Reply

            Yeah, I got this reply on my phone and found myself asking “Good point, what DO I actually mean?!?”

            I suppose for me, as a developer, I expect to see revisions for comparison. I would rarely expect the system to make decisions about which version I wish to chose without my input. Therefore, I suppose in that context, it makes more sense to me to have the content available for comparison WITHOUT the strike through. However, having said that, it is not always programmatically that one might be looking at this feature (I recently had to point out to a journalist who uses WordPress every day for their news site, how to find revisions. To say I was popular as a result would be an understatement!). In this instance, it would make more sense to see them in the context of their title (i.e. as a REVISION) and in that situation, the strikethrough makes perfect sense.

            On the whole, I like the strikethrough as an idea and I do believe, based on Esmi’s examples, it will still be legible. My comments were really, solely based on the wireframes which, having drawn them up myself in the past, I figure is just a factor of the wireframe implementation, than on real life representations of the same.

            Possibly still up for discussion a bit, as I haven’t really answered any questions proper here, but hopefully this gives a bit of clarity on my stance and the context of my original point.

    • esmi 5:12 pm on February 14, 2013 Permalink | Log in to Reply

      Will this render similar to the example you created above

      Yes — see the latest screenshots. I know what you mean but, as far as I am aware, strikethrough is the default treatment for the del tag in graphical browsers since about 1998. Not sure if we should mess around with that too much.

      • Joe Dolson 6:08 pm on February 14, 2013 Permalink | Log in to Reply

        There are some sneaky things that can be done with CSS to modify the apparent weight of strikethrough that can make it a little easier to read:

        del{
        position: relative;
        }

        del::after{
        content: ”;
        border-bottom: 1px solid red;
        position: absolute;
        left: 0;
        top: 50%;
        width: 100%;
        }

        I don’t know whether that’s a good idea, but it would be possible. As I understand it, IE and Firefox increase the weight of the line with the font-weight and size, and this would prevent that from obscuring the text.

        • _Redd 6:23 pm on February 14, 2013 Permalink | Log in to Reply

          @joe, (I want to call you AWESOME Joe for that plugin work you’re doing!!)

          Before pursuing that, let me try to reproduce a problem I had earlier with fancy text-I recall that when manipulating text with some fancy CSS, I found out that the text would not print!

          It was bizzare!

          I promise, I could not or would not make this stuff up. I’ll try and find my old records to see what I did to cause that to happen, but I don’t think it was anything more fancy than adding a border on the bottom to simulate a shadow. I was stunned to see that it caused text not to print.

        • tady 8:16 pm on February 14, 2013 Permalink | Log in to Reply

          Yeah, I’d avoid this on the basis of experience. I’ve never had much joy in replacing a typeface representation with a graphical equivalent. An example would be trying to make the underline on links as a dashed element as opposed to a solid line. It just never really works cross browser with the same stability as the actual (text-decoration:underline, etc) typeface formatting. There’s also the question that the difference or revision may not just be a whole paragraph, but could be a word or a phrase. Applying positioning to this element inline won’t always layout the best. I really can’t emphasise how much I’d shy away from this substitution.

          • Joe Dolson 11:09 pm on February 14, 2013 Permalink | Log in to Reply

            For clarity, it’s not the del element that’s being positioned, it’s a dynamically created element with an independent border being overlayed. Regardless, I don’t disagree: and it’s not certain it would really be any improvement, if the font in use is of average size and weight, anyhow. Although I suppose you could reduce the opacity, as well.

  • esmi 11:30 am on February 8, 2013 Permalink
    Tags:   

    Post Revisions in 3.6 

    The Post Revisions are currently being overhauled for WordPress 3.6. The team responsible are at the concept stage & they’ve asked asked us to provide feedback now on their current mock-ups.

    I have already raised the point elsewhere that perhaps a red/green combination isn’t the best of choices but I do think that the potential barriers here could be greatly mitigated if one of the mock-ups with strike-through (currently the favoured approach) was chosen. The screenshot below shows how these screens might be viewed by someone with the most common forum of colour blindness (protanopia).

    Full size mockup of protanopia view

    Seems to me that the markup used could also greatly enhance accessibility here — with proper use of both the <ins> and <del> HTML tags.

    Any other thoughts?

     

    • ceo 11:49 am on February 8, 2013 Permalink | Log in to Reply

      I’m completely colorblind so the color differences are basically lost on me. Highlighting does draw attention to the different text, but does also make it harder to read in some cases. I like the idea of the strikethrough text.

      • esmi 12:52 pm on February 8, 2013 Permalink | Log in to Reply

        When I checked the foreground/background color contrast on the last round of mockups, the red just failed but the green was failing badly. We definitely need to ensure that the contrast remains at least 4.5:1

        • ceo 6:31 pm on February 8, 2013 Permalink | Log in to Reply

          @Redd said my thoughts below – the background color changes are MUCH better than changing the text itself, but I like the idea of that plus the strikethrough personally.

    • Joseph Karr O'Connor 11:51 am on February 8, 2013 Permalink | Log in to Reply

      Thanks for applying the protanopia filter. Is there a built example where we could use AT or accessibility checking routines? I will have to experiment with strike-through and SR.

      • esmi 12:56 pm on February 8, 2013 Permalink | Log in to Reply

        This is still at the mock-up stage, so no. When I get a chance, I do intend to start looking at setting up an install that uses SVN and where I can apply specific patches for testing. Access to this install will be available on request. But right now, I’ve not even had a chance to locate the documentation on setting up this kind of install yet. — let alone read it.

    • Redd 12:51 pm on February 8, 2013 Permalink | Log in to Reply

      The use of color as a way of passing information about the status of the text is definitely a problem for many of my students and the general population, especially when the colors are so close in “value” to each other.

      That said, when I made further explorations of the proposed interface here:
      http://make.wordpress.org/core/2013/02/05/revision-update-25/#comment-7943

      I found the text’s background is highlighted—and a huge improvement. That background highlight actually improves readability/comprehension, because it facilitates cognition, and it does so rapidly—visual areas are organized into great groups by placing a background color to the paragraphs. It’s similar to the “outline” function in a:focus…..serves the same purpose.

      I personally support the text background highlighting (NOT highlighting the text, highlighting the background)—WITHOUT the use of color as “code” for what is happening.

      It’s really awesome how Eric and the 3.6 Post revisions team shared this for comment. Super great!

      • esmi 12:59 pm on February 8, 2013 Permalink | Log in to Reply

        So what about a highlight background plus strike-throughs and <ins> and <del> HTML tags? With checks for contrast levels?

    • karmatosed 12:59 pm on February 8, 2013 Permalink | Log in to Reply

      I’m one of those working on the revisions team and would like to thank you all for your feedback on this. My plan is to listen and work on a revised mockup based on suggestions (or few as the suggestions come). From there we can look to have it made into something code based when tests can be run on the patches.

      Thank you all though for your fast responses on this and looking a this – it’s really cool.

    • Redd 1:05 pm on February 8, 2013 Permalink | Log in to Reply

      I personally am a little worried about the strike-through, although I feel they are an improvement. In a sense, strike-thoughs add “details” to the text, and that is more “stuff” one has to sort through, cognitively, when looking at a page.

      That said, I would still support a strike-through because because it outlines in no uncertain terms what is intended to happen to that text.

      Maybe, a case where the text has strike-though and a background highlight to facilitate both cognition (outlining a paragraph via a background highlight) and signaling intent (through the strike-through). The fact that a light-colored background “softens” the visual distinction of the text around it might also soften some of the “messiness” of the added details that the strike-through brings, making it all a little softer on the eyes.

      In other words, maybe we can have our cake and eat it too?

      • Redd 1:11 pm on February 8, 2013 Permalink | Log in to Reply

        Doh! Sorry esmi….you said strike-throughs PLUS highlights…….

        Definitely YES!

        I better get more coffee! And a little more sleep! ;-)

    • tady 2:55 pm on February 8, 2013 Permalink | Log in to Reply

      FYI, <ins> and <del> tags can also use the datetime attribute, which would certainly also be helpful for highlighting date differences between revisions.

      • tady 2:56 pm on February 8, 2013 Permalink | Log in to Reply

        Dammit, formatted my post instead of showing the tags. What I said above is that the <ins> and <del> tags can use the datetime attribute. (Crosses fingers)

        • Redd 3:30 pm on February 8, 2013 Permalink | Log in to Reply

          To esmi and tady, absolutely, positively YES in regards to the use of the <ins> and <del> tags….if those tags are able to use datetime attributes in addition to being able to to strengthen the visual presentation of the text, then all the better.

          I was not aware that the tags could use the datetime attribute! I’m going to try to incorporate them in my scratch site when I have a chance, to see what that’s all about!

          • Redd 3:31 pm on February 8, 2013 Permalink | Log in to Reply

            Well! I did the same thing, tady! Left the tags open……..so I “struck out” ! Heh…

            • tady 4:29 pm on February 8, 2013 Permalink

            • tady 4:32 pm on February 8, 2013 Permalink

              Actually, it also supports the “cite” attribute. I missed that. That also could be a helpful addition. I don’t quite know what you’d cite (author name?) but it might be beneficial for some features.

            • Redd 8:03 pm on February 8, 2013 Permalink

              tady, the link you provided was AWESOME. I’m still reading it
              !

              I guess I have a couple of concerns about using the tags now….I’m not saying “no”, I’m just saying I have some second thoughts….

              the first, is that although I try to use HTML5 whenever and wherever possible, I’m not sure the standards have “gelled” sufficiently for WordPress to rely on it. There’s a honking big red warning to that effect on the pages covering those tags

              The second is that apparently, The content models of the ol and ul elements do not allow ins and del elements as children (See section 4.7.5 Edits and lists)

              I think whatever is chosen, the visual feedback needs to be consistent through the editing process. I worry users would have expectations that the lists would be treated the same way as the other content when revising. So, if HTML5 ins and del tags aren’t supported in lists, I would be a little more hesitant to implement it.

              I’m just thinking out loud right now……What are your thoughts?

            • Redd 8:22 pm on February 8, 2013 Permalink

              One other thing…..I’m not sure, but I think most screen-readers are not set up for HTML5 tags. If I understand the situation correctly, screen readers largely incorporate HTML4 technology, so maybe we shouldn’t be considering HTML5 types of tags for critical visual information…..or if we do, maybe we should ensure some sort of coding to work in concert with the tags…..but oh my gosh, that’s a LOT of follow-up work. And, for that reason, would be prone to errors from being missed.

            • esmi 8:45 pm on February 8, 2013 Permalink

              <ins> and <del> have been part of the HTML specification since… um… 3.2 at least :)

            • Redd 9:20 pm on February 8, 2013 Permalink

              ins>and del have been part of the HTML specification since… um… 3.2 at least

              …oh…I am burying my head in the ground in embarrassment…….looks like I STILL need more coffee! Thanks esmi! :-)

            • esmi 9:24 pm on February 8, 2013 Permalink

              No problem. They’ve always been very under-used tags, so people just forget about them.

    • tady 10:34 pm on February 8, 2013 Permalink | Log in to Reply

      Yeah, it happens. I had to explain the marquee tag (and why NOT TO USE IT EVER) to someone lately. It’s like the and tags. A lot of people don’t know about some of the older tags because they’re used so irregularly. Not to worry Redd, you learn something new every day! I think the datetime element of them could be new. I don’t think any of the 3.2 or 4 spec HTML tags supported datetime, so that may be a HTML5 attribute, but eitherway, the datetime attribute on it’s own is supported by the majority of screen readers currently. What is worth noting is that they don’t all appear to handle it the same way. The default recommendation is that the datetime attribute holds the date/time in ISO format (that’s the long one, without looking it up, that looks something like 2013-02-08-23-30-00+00ZT). There’s nothing that says this attribute has to be specifically included this way, just that’s the development recommendation (I assume because it’s easier handled from a machine code perspective). Screen readers have funny ways of interpreting this, so it might be worth while if, as in this example, the datetime attribute is being used SOLELY for accessiblity reasons, to include a more “real” format (e.g. Friday, 23rd Feb 2013 at 11:30pm UTC). I’m not sure how this will fly with the devs, but worth mentioning overall I suspect.

      Anyway, glad to have been some help. Like I said before, intend on contributing more than I have been up to now.

      • tady 10:42 pm on February 8, 2013 Permalink | Log in to Reply

        Also @Redd, with regard to HTML5 not being supported right now, this is mostly correct, but the ideal method of coding HTML5 is to include ARIA roles and attributes. This is not really being supported by the large majority of developers in reality at the moment, but the more this is incorporated into well known CMS systems (like WordPress) the greater adoption rates will be. I personally have no problem with using HTML5 templates from a theming perspective (mostly using a modified version of Elliot Jay Stocks “Starkers” theme), though I can appreciate the reservations from a backend perspective. It may also be a bit late in the game for 3.6 to include ARIA roles (this also puts great onus on plugin developers), but certainly worth considering. Not saying you’re wrong Redd, but on the basis of what the HTML5 WG are aiming to do, ARIA is front and centre. Jeremy Keith, Bruce Lawson and many others are firmly pushing the accessible element of HTML5. I fear it is the community who use it, as opposed to those who define it, will affect how accessible it is overall.

        But hasn’t this always been the way!?

        • esmi 11:17 pm on February 8, 2013 Permalink | Log in to Reply

          +100

          It’s not our place to support the assistive technology (AT) out there. It’s our job to design pages the “right way” — according to the current specs & guidelines– and let the AT software developers do their own thing. We don’t design for specific browsers anymore, so we also shouldn’t support specific AT.

          The only thing I would say about ARIA roles & attributes at the present time is that we shouldn’t rely too heavily upon them yet. Progressive enhancement and graceful degradation is always a good rule to develop by.

      • Ryan McCue 9:45 pm on February 13, 2013 Permalink | Log in to Reply

        As in in-between, what about an RFC 2822 date? That looks like “Thu, 21 Dec 2000 16:01:07 +0200″ which is human readable (maybe harder for international users) but still machine parsable.

        • esmi 12:33 pm on February 14, 2013 Permalink | Log in to Reply

          As long as the format is machine readable and can be parsed by screen reader software, I don’t think the actual format of the date matters. I’ll try to set up a very simple comparison test to get some real feedback on this.

    • tady 1:15 pm on February 9, 2013 Permalink | Log in to Reply

      Of course, that’s very true Esmi. Personally I’m all in favour of including ARIA roles in my own work as I feel it’s better to have something than nothing. While HTML5 is still settling, my preference is to offer something. I don’t actually know how helpful it is, but I figure it must be better than saying “I’ll just wait and see!” :D

      Anyway, great discussion, looking forward to seeing the outcome.

      • Redd 1:01 pm on February 11, 2013 Permalink | Log in to Reply

        t’s not our place to support the assistive technology (AT) out there. It’s our job to design pages the “right way” — according to the current specs & guidelines– and let the AT software developers do their own thing. We don’t design for specific browsers anymore, so we also shouldn’t support specific AT

        Well, that statement put it in perspective for me. Thank you both, esmi, and tady, for the feedback. It actually helps provide direction for what I’m doing here at “home” so to speak. With that, let’s move forward–with modern tags! :-)

    • John Saddington 2:07 pm on February 9, 2013 Permalink | Log in to Reply

      • Redd 1:03 pm on February 11, 2013 Permalink | Log in to Reply

        Not only “Neat”, but another awesome article I’m going to pass around at work. Keep ‘em coming!

  • esmi 4:02 pm on February 6, 2013 Permalink
    Tags: ,   

    IRC: Proposed Schedule 

    Venue: #wordpress-ui
    Server: irc.freenode.net or via freenode web chat.
    Time: Wednesdays, 20:00 UTC

    Meetings should take no more than 1 hour — possibly less. If anyone is available today, I should be around at that time.
    First official meeting will be February 13.

    First orders of business:

    1. Define this group’s role in the overall development of WordPress
    2. Look at intra-group organisation as a possible way to circumvent that “totally overwhelmed” feeling.
    3. Discuss the development of semi-formalised, pan-disability, user testing
     

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

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

    • andrea_r 1:57 pm on February 6, 2013 Permalink | Log in to 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 | Log in to 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 | Log in to 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 | Log in to 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 | Log in to 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 | Log in to 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.

    • Joe Dolson 3:42 pm on February 6, 2013 Permalink | Log in to 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 | Log in to 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 | Log in to 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 | Log in to 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 | Log in to 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 | Log in to 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 | Log in to 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 | Log in to 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 | Log in to 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 | Log in to 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 | Log in to 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.

    • esmi 11:50 am on January 11, 2013 Permalink | Log in to 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 | Log in to 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 | Log in to 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 | Log in to 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 | Log in to 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 | Log in to 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 | Log in to 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 | Log in to 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 | Log in to 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 | Log in to 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 | Log in to 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 | Log in to 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 | Log in to 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.

  • esmi 3:56 pm on January 8, 2013 Permalink
    Tags:   

    Menus 

    Graham Armfield has asked for the Menu UI to receive some accessibility attention.
    Associated Trac link.

     

    • Graham Armfield 9:43 am on January 9, 2013 Permalink | Log in to Reply

      Thanks for posting about that Esmi, I believe it is vital that everyone who maintains a site in WordPress should be able to fully create their own menus.

      Of course at the moment the order of menu items and the hierarchy can’t be changed without the ability to drag and drop – an alien concept for some people and for some assistive technology like screen readers.

      Sighted keyboard users can manipulate menus if they know about mouse keys, and speech recognition users can do drag and drop commands although it’s hard to get things precise enough some times.

      But, how to make the menu builder accessible to everyone?

      Is the best way to add an accessible option – similar to the one that exists for managing Widgets (which has similar-ish functionality)?

      Or is there another way that would work better for everyone?

      And (perhaps similar to other areas within WP) are there sufficient instructions clearly available so that everyone understands what they are changing and how to go about it?

      • esmi 11:48 am on January 9, 2013 Permalink | Log in to Reply

        Adding an accessibility option similar to the widgets one has to be the absolute minimum fallback, in my opinion. I’ve already seen calls elsewhere on the support forums for it to be added to menus. It would also lend itself nicely to some sort of consistency across the WordPress UI.

        Are there any other web applications with accessible drag and drop functionality that we could use as a best practice model?

        • Cyndy Otty 1:56 pm on January 9, 2013 Permalink | Log in to Reply

          From the standpoint of a blind person “accessible drag-and-drop” is kind of an oxymoron . . . it’s inherently a mouse-user feature and those are notoriously difficult, if not impossible to translate to use for a screen-reader user.

          • esmi 2:17 pm on January 9, 2013 Permalink | Log in to Reply

            Do you find the accessibility option in the Widgets section useful? Would a similar option for Menus help?

            • Cyndy Otty 2:20 pm on January 9, 2013 Permalink

              I do actually. I think I’ve voiced a similar suggestion for that in the Menu screen before. (Seems like something I’d natter on about.)

      • GrahamArmfield 9:48 am on January 11, 2013 Permalink | Log in to Reply

        Just to let everyone know there is a whole load of debate about the UI for Menus going on over at: http://core.trac.wordpress.org/ticket/23119 but so far there is no mention of accessibility in there.

      • GrahamArmfield 12:12 pm on February 6, 2013 Permalink | Log in to Reply

        Just to let people know there is still much debate going on about the new UI for custom menu builder. You can follow it here: http://core.trac.wordpress.org/ticket/23119 and there is a big thread on http://make.wordpress.org/ui/ too.

        So far I’ve seen no real mention of addressing the accessibility issues – either with the existing functionality, or with any of the proposed functionality. I’m of course specifically talking about the drag and drop nature of setting the menu order and hierarchy.

        • esmi 12:54 pm on February 6, 2013 Permalink | Log in to Reply

          I’m just wondering if we should create a new Trac ticket regarding the menu system’s accessibility issues. It seems to me that it might be possible to re-use the accessibility option currently available for the Widgets on the Menus too. Thoughts?

← 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