WordPress.org

Ready to get started?Download WordPress

Make WordPress Accessible

Tagged: core Toggle Comment Threads | Keyboard Shortcuts

  • Helen Hou-Sandi 9:21 pm on September 24, 2013 Permalink
    Tags: core,   

    Feedback on #21334: Row actions are not always keyboard accessible 

    I’ve made two commits so far to address the fact that row actions (that is, edit/quick edit/trash under each post’s title) only show on hover. I have two questions regarding this that I could your expertise on:

    1. In terms of CSS, this is controlled by the visibility property. My understanding has been that visibility: hidden does not get read by screen readers. If this is the case, then we may want to use an alternative method for show/hide. Are these row actions currently in a state where they are useful to screen readers or are they better off not being read (for now)?
    2. Right now the keyboard tabbing will only trigger them to show when in the same cell. Should this expand to whenever focus is within the row? I believe visually it is when hovering on the table row.

    Thanks!

     
    • PhilippeVay 12:28 pm on September 25, 2013 Permalink | Log in to Reply

      Hi,

      both display: none; and visibility: hidden; aren’t read by screen readers, that’s correct. There are now other CSS techniques that will also hide content but not on all screen readers (ex: height: 0).
      The well-named WP class .visually-hidden will move content off viewport so it’s still read by screen readers but not visible to sighted users with CSS activated: it’d be a good alternative to hide content only to sighted users.
      Useful or not here? I haven’t been active on WP for a while so I’ll have to take a look to these actions first :)

      Concerning keyboard and hiding content: I think there are 3 categories of disabled people that have different needs and habits.

      • blind people will use keyboard and a screen reader,
      • low vision people may use mouse and/or keyboard and a screen reader or not. The four combinations are possible
      • motor impaired will probably use a keyboard but no screen reader

      Screen reader may access rich information in an accessible table (related to header cells of a particular cell via scope – or id/headers – attributes) even if a link or button is off viewport while motor impaired wouldn’t be able to interact with this same table. So I think it’d be better to show all actions in the current row if one of the links has taken focus.

    • Joe Dolson 2:58 pm on September 25, 2013 Permalink | Log in to Reply

      I generally agree with Philippe.

      Keyboard tabbing should trigger the links, I think, whenever focus is in the row; that will maximize awareness of these options. It’s not critically necessary, but when it comes to being able to find and understand the options, this will be the better solution.

      For screen readers, just using the visually-hidden solution, so that the links are always available for screen reader users is, in my opinion, the best solution. It does run into the repetitive-link problem, but I honestly think that in this user interface that’s not really an issue; it will be more valuable to be able to have those links available in context.

    • Helen Hou-Sandi 2:02 am on September 26, 2013 Permalink | Log in to Reply

      Thanks so much for the quick feedback – based on the IRC chat, it seems that the solution that is in the current nightly might actually be for the best, due to lack of context for screen readers and the sheer number of links that would appear. Perhaps things can be improved in the future for screen readers in this regard, although these links are convenience and not exclusive to the area. For 3.7, let’s focus on getting it just right for keyboard tabbing. We actually need to get this done in the next couple days, so I look forward to any further feedback, but do note that there’s a chance that further improvements will have to wait until 3.8 if this drags on.

    • _Redd 7:23 pm on September 27, 2013 Permalink | Log in to Reply

      Hi Helen, from what I can tell from running a very brief test, the quick links menu is available upon the first visit to the post, and it allows you to get into the quick edit menu and perform edits, but once that takes place, the quick edit menu disappears and is no longer available to a screen reader (at least NVDA).

      Would you like access to my test site?

    • _Redd 8:36 pm on September 27, 2013 Permalink | Log in to Reply

      I’m sorry, Helen, I forgot to include an example of what I’m talking about. Here is the link to the site.

      Once again, we are all really appreciative of what you’re doing for us. You are the BEST!

  • esmi 8:01 pm on June 25, 2013 Permalink
    Tags: core, ,   

    Next IRC Meetup 

    Just a quick reminder that the next IRC meetup will be on Wednesday, 26 June at 19:00 UTC in #wordpress-iu.

    Everyone welcome!

    If you have never attended an WordPress IRC meetup before, you can find all of the details you will need to join in the Codex’s IRC page.

    One topic for discussion is likely to be the development of a proposed accessibility statement for WordPress. To whet your appetite and give you an idea of what we could aim for longer term, have a look at Drupal’s accessibility statement.

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

    Accessible Dialogs and Popups 

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

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

    My response to him was:

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

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

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

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

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

      with target=”iframe-name”.

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

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

      Thanks for EVERYTHING

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

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

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

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

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

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

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

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

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

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

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

    WordPress 3.6 alpha Testers 

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

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

      Can you make trac tickets for each of these?

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

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

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

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

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

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

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

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

  • ceo 2:25 pm on February 21, 2013 Permalink
    Tags: core, , , , ,   

    IRC Meeting Summary: 20 Feb. 2013 

    As evidenced by our small group at yesterday’s meetup, I want to first remind you all that we could very much use new members! Whether you are a developer and very technical or merely a writer with special needs, we would certainly welcome you to join us. Anyway, despite our numbers and lack of a formal agenda, our main discussion was on two topics that will be our primary focus presently.

    Custom Menus

    As the trac ticket concerning design changes to the Custom Menu has been closed, we discussed centering accessibility discussion around the reopened trac ticket #14045. The proposal is for an accessibility mode screen alternative like that which the Widgets page utilizes. We also have a post devoted to this topic here as well for your consideration and comments.

    Twenty Thirteen

    Feedback is strongly requested from an accessibility standpoint on the new default theme Twenty Thirteen, which is currently being developed. You can check out the theme here at the Twenty Thirteen demo site and please report any feedback you have.

    The full log of yesterday’s IRC meeting can be found here at #wordpress-ui logs for February 20, 2013.

     
  • esmi 5:03 pm on February 20, 2013 Permalink
    Tags: core, ,   

    Twenty Thirteen 

    Development on the next default theme — Twenty Thirteen — has now reached a point where our feedback is needed. You can see and use the theme (currently still in alpha) at its own Twenty Thirteen demo site.

    Please post all feedback here. If you are using assistive technology to browse the demo site, please indicate exactly what software you are using — including the version number, if possible.

    Come on, people. If you want a truly beautiful example of an accessible WordPress default theme, now is the time to point out any issues and support the theme’s developers.

     
    • esmi 5:06 pm on February 20, 2013 Permalink | Log in to Reply

      I’ll kick off…

      I’ve been looking at the theme from the viewpoint of a sighted keyboard navigator using the TAB (or equivalent) to move around the demo site.

      Keyboard Navigation
      Like the skip menu link but some focus highlighting on links right across the theme is desperately needed. On post title links with the pale/yellow backgrounds (standard, aside, chat & gallery formats), I’d suggest changing the background color to #f24b12. On the orange background for video & audio formats, try #fccb27. On quote posts, maybe something like try #fccb27 for the background and #141412 for the text.

      On the next/previous post navigation, perhaps replicate the hover CSS image change but definitely provide highlighting on the link itself the link text — maybe try #fccb27 for the background and #141412 again?

      Given the range of colors being used for different post formats (which I love, by the way), we need the currently focused link to really “pop”. Otherwise, it’s far to easy to get “lost” as soon as you move into the page.

      Contrasts
      Link contrasts generally need improving. For example links in standard posts (#f94a0a on#fff) have a link contrast ration of only 3.5:1 instead of 4.5:1. Change the link text color to #d93f08 & that issue is solved. Ditto the text in the footer where the ratio is only 3.1:1. Try #62605b for footer text instead.

      Other Concerns
      Links are not immediately obvious in status or quote posts. You have to “mouse scrub” the post content area to “discover” the links as their text is too close to that used by the plain text. The link text wither needs changing or those links need to be underlined (maybe with the underline removed on hover?).

    • GrahamArmfield 5:29 pm on February 20, 2013 Permalink | Log in to Reply

      Also from a sighted keyboard perspective (and from screen reader) I’d like to add that the horizontal primary menu has sub items in some places. But these do not become visible when the top-level menu item is tabbed to.

      In my view the sub items should dropdown on focus or else there is a real danger that entire parts of certain sites could be ‘hidden’ to keyboard users if the site owner has not provided other ways of navigating to sub-sections of the site.

      I echo your comments about more visible focus and links in general.

      • ceo 5:52 pm on February 20, 2013 Permalink | Log in to Reply

        I can second this using JAWS 9.0 as a blind person. In Firefox the navigation menu itself seems to be entirely skipped over. I can see the links within the link list option mode, but moving through the page itself I can’t find the menu. (I see the “skip to content” and then “search” and the actual menu is not there…) I do see it in Internet Explorer, but as Graham mentions, the submenu is essentially hidden.

      • esmi 6:55 pm on February 20, 2013 Permalink | Log in to Reply

        In my view the sub items should dropdown on focus

        I’m very much in two minds about this. If the sub items did drop down on focus, then we risk forcing people to tab through a whole stack of links unnecessarily. I have seen so many massive menus on the WPORG support forums (featuring 50 or more sub-menu links) that would be nightmare to navigate through.

        In an ideal world, my preference would be for no sub-menu dropdowns for keyboard navigators but a “pages in this section” sub-menu within each main menu page. But sadly, I think the latter could be outside the direct remit of a theme as core doesn’t offer much of use here — especially when you add in custom menus.

        • GrahamArmfield 4:13 pm on February 21, 2013 Permalink | Log in to Reply

          Providing multiple ways of accessing content on a site is of course very important – and one of the WCAG2 guidelines. But, I fear, that it is something that doesn’t always happen.

          I use functionality just as you suggest on many client websites that I’ve done, and I even have a plugin that can be used as widget called Child and Sibling Pages which does just that. It’s not ready for general release yet but I can make it available to others if requested. It’s current limitation is that it relies on strict page hierarchy which I tend to do for clients. So it may not show the ideal selection – either too much or too little.

          I guess the ideal solution here would be a way to hook into an appropriate custom menu to pull out an appropriate part of the page hierarchy. Maybe: 1) search for me in custom menu 2) If found, pull out siblings and children from that menu and list accordingly. 3) If I can’t find myself show nothing.

          I’ll have to check if there’s a way of accessing a custom menu structure from outside.

          In the meantime I favour showing the submenu items on hover for the reason I outlined above. When presenting about accessibility I use this site as an example: http://www.crowncourtchurch.org.uk/ You can see it’s based on 2010 and there are dropdown menus. However, because the menus aren’t keyboard accessible whole swathes of the site can’t be reached.

    • tady 5:50 pm on February 20, 2013 Permalink | Log in to Reply

      Ok, from a fully able user’s perspective, the primary thing I notice is the “Skip to content” link is really positioned all wrong on tabbing. It’s appearing over the primary nav.

      Also there appear to be a HELL of a lot of JS libraries and embedded styles in the header. Is there really an need for all these?

      No title attribute on PopSci image. Not coded in or not included in media library?

      Pretty much the same observations as Graham and Esmi. Some UI issues on Android smartphone, but flagged those in trac.

      • esmi 7:13 pm on February 20, 2013 Permalink | Log in to Reply

        the “Skip to content” link is really positioned all wrong on tabbing. It’s appearing over the primary nav.

        Well spotted. Shifting it up a minimum of 55px would help with that.

      • Konstantin 1:00 am on February 21, 2013 Permalink | Log in to Reply

        there appear to be a HELL of a lot of JS libraries and embedded styles in the header.

        They are wp.com specific and not part of the theme.

    • Sveta 6:30 pm on February 20, 2013 Permalink | Log in to Reply

      The video shown is not captioned and transcribed as required by web accessibility guidelines – http://audio-accessibility.com/solutions/best-practices/make-captions/.

    • _Redd 6:48 pm on February 20, 2013 Permalink | Log in to Reply

      The theme is GORGEOUS. I am in love. Be still my beating heart. I want it I want it I want it.

      That said, navigation is a problem, and the reasons why have already been outlined above by those more expert than me.

      And, unfortunately, as much as I love that color orange, burnt orange is one of the hardest colors in the universe by which to embed text with sufficient contrast of ANY color. Contrast is a problem throughout, but In particular, when the links are hovered over, the color becomes too light for perception among many viewers, even against the white background.

      I’m concerned about the setup for search. Even as a sighted user, one has to exactly hit the search icon, rather than tab into a box, and that will create problems. First, it presumes/assumes that people understand that the icon “means” search, and I can tell you that a lot of people just think it’s a decoration, not a cue to search. Secondly, there’s a presumption that the user doesn’t have any motor skill problems with their hands to get to that search icon. The “target” is too small.

      Handling search is one of the most critical things ANY site can have, because a modern user just doesn’t have the patience to look at links, indexes, or whatever. If search isn’t first and last in visibility and usability, users will just leave the site. At least, the young ones will.

      Again, though, the theme is GORGEOUS–I really, really love it. There’s problems with functionality as far as getting around the site, but hey, there are ALWAYS problems…and the WordPress developers have always been awesome at solving anything. I know this thing is going to knock it out of the ballpark! And, the theme is so beautiful, it makes you want to do anything in your power to make it work….

      • GrahamArmfield 7:02 pm on February 20, 2013 Permalink | Log in to Reply

        Haven’t had a chance to test with Dragon yet but I’d imagine that directly selecting the search box might be difficult. It’s never a good idea to force VR users to rely on tab commands or moving the mouse pointer about.

        • esmi 7:08 pm on February 20, 2013 Permalink | Log in to Reply

          Using what browser? As I understand it, Dragon + IE (the recommended set up) results in the user having numbered links that they can use. If it’s a non-IE browser… well, that’s user choice and outside of the remit of a theme,.

      • esmi 7:06 pm on February 20, 2013 Permalink | Log in to Reply

        burnt orange is one of the hardest colors in the universe by which to embed text with sufficient contrast of ANY color.

        I think it’s still just possible though. :) And I think the theme could be “accessified” without too much disruption of the current color scheme with a bit more tweaking.

        Even as a sighted user, one has to exactly hit the search icon, rather than tab into a box, and that will create problems.

        Not sure I agree with this. I had no problem tabbing into the search input box (which expands nicely on focus) and, at 34 x 37px by default, I don’t think the search icon is too small — although a few more pixels padding to the left might be nice — and it zooms nicely too.

        it presumes/assumes that people understand that the icon “means” search

        I’d argue that it’s a reasonable assumption to make — particularly when supported by its placement (most users will look in the upper right area for a search box, in my experience).

    • GrahamArmfield 7:03 pm on February 20, 2013 Permalink | Log in to Reply

      Mel I know there was a post about 2013 theme on another board originally, will you be collating all the responses on here for the Core/UI team?

    • esmi 7:16 pm on February 20, 2013 Permalink | Log in to Reply

      I wasn’t aware of any other discussions. Link?

    • esmi 9:15 pm on February 20, 2013 Permalink | Log in to Reply

      I’d argue that the other thread is really more on general design issues and introducing the theme (and the principles behind it) generally. Lance Willet (who is part of the 2013 design team) is specifically looking for a11y feedback from here.

    • David A. Kennedy 4:09 am on February 22, 2013 Permalink | Log in to Reply

      First off, the theme looks and feels fantastic. It really has more personality than some of the past default themes (but still fits with them nicely) and I love the focus on blogging.

      I’m approaching this as a sighted user using Apple’s Voiceover with Chrome and Safari. I also did some light testing with the Wave Toolbar.

      I’m also guessing we’re not shooting for 100 percent WCAG 2.0 standards, so I’m aiming to be more pragmatic than anything.

      Links
      I generally like to see links underlined with text-decoration or have some kind of border in the main content area (or in paragraphs at the least), but I realize this might not be in the design aesthetic.

      I’d like to see the “Continue reading” and excerpt links get coupled with titles so they have more meaning. For example, “Continue reading “My Awesome Blog Post” > Generic read more links aren’t that helpful, generally speaking.

      Link Focus
      It’s very good overall, but I’d like to see:

      Focus styles similar to hover on the .main-navigation.
      Focus styles similar to hover on the .page-links.
      Focus styles similar to hover on the .nav-links.
      I’ll echo Graham’s comments about the sub-items in the .main-navigation. I’d like to see them become visible on focus.
      I’d like to see linked images get a more prominent hover/focus treatment. Maybe a 1px or 2px border.

      The .page-links and .nav-links are especially hard to see the focus because they are already the orange color, matching the focus indicator.

      Text Size
      Lots of people use page zoom to increase font size if need be, but I’d love to see the theme move away from pixels for font sizing and to a fluid approach with percentages or ems, making the content more flexible if need be. This would also harmonize well with the responsiveness of the theme.

      Forms
      I got an error from Wave Toolbar about two form labels associated with the search for, but glancing at the source code, I think that’s a false error.

      Let me know if you all have any questions. I might dig in a bit deeper this weekend. This is really is a great effort. I’m excited to see all this feedback and pumped that Lance and company are looking for it. There’s awesome stuff going on with accessibility and WordPress!

    • Michael Boer 7:09 pm on February 27, 2013 Permalink | Log in to Reply

      Twenty Thirteen is very nice, but adding a few standard WordPress widgets to it is all it takes to spoil it. For example, widgets like Categories and Archives raise red flags in the WAVE toolbar. Patches to fix this have been available for more than 6 months, but are still “awaiting review,” right? See: https://core.trac.wordpress.org/ticket/18650 What does it take to get WordPress to review a patch that relates to compliance with Section 508?

    • esmi 7:33 pm on February 27, 2013 Permalink | Log in to Reply

      Any issues with core widgets are outside of the remit of the theme and should be dealt with separately. No themes should ever be forced jump through hoops to patch a core issue. The problem needs fixing at the source.

    • C0BALT 8:30 am on March 4, 2013 Permalink | Log in to Reply

      If you use a plugin like this which hides the admin bar after a certain amount of time on the front end if you are logged in…
      Auto Hide Admin Bar
      http://wordpress.org/extend/plugins/auto-hide-admin-bar/

      then the new twenty-thirteen theme toolbar is offset by 16 or so pixels and shows a hole between it’s top and the top of the browser.

    • esmi 11:53 am on March 4, 2013 Permalink | Log in to Reply

      That’s not an accessibility issue. You need to raise this with the theme’s development team directly.

  • esmi 12:29 pm on February 14, 2013 Permalink
    Tags: core, 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: core,   

    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 12:05 pm on February 14, 2013 Permalink
    Tags: core, , ,   

    IRC Meeting Summary: 13 Feb 2013 

    As per last week, we had a very lively and interesting meeting with the main focus being Custom Menus (again) and the use of hidden skip links. Thanks to all who took part — especially a couple of UI team members. The inter-team discussion is invaluable as it allows us to get a better perspective on the overall core development philosophies as well as the current development cycle goals. I think the more we learn about the development process, the more effective we can become at offering practical, effective, suggestions at the right times.

    User Testing

    @accessiblejoe will be looking at developing videod user tests for the CSUN conference based on the list provided by @GrahamArmfield and the alter discussion on IRC:

    • Logon and interpret dashboard and toolbar
    • Publish new post including use of headings, bold etc. Add categories and tags.
    • Edit post to add media (image or pdf) with caption, alt text etc.
    • Update user options including setting new password
    • Use Theme Customizer to change Site Title and background colours etc.
    • Creation of a simple custom menu; re-ordering of menu items including a single item sub-menu.
    • Logging out of WordPress.

    We hope that any videos obtained will help the core development teams to gain a better understanding of some of the issues faced by disabled users.

    Front-end Accessibility

    @joedolson is still working on an extension of the Theme Check plugin as part of the optional accessibility audit for all themes submitted to wordpress.org. He now has a modified version of the plugin available for testing and is actively looking for feedback.

    There was also a lively discussion of “hidden” links — including both skip links and the current log out link (which is effectively hidden in a dropdown) — and balancing link visibility with the need to avoid a cluttered interface.

    Finally, a reminder to all readers that, as a group, we are still stretched pretty thin and would welcome new members — both technical developers and non-technical disabled authors.

    #wordpress-ui log for February 13 2013

     
    • ceo 12:34 pm on February 14, 2013 Permalink | Log in to Reply

      Catching up on the chat after I left. I really like the idea of the visible Logout. Glad to see this brought up.

      And, in my experience, most of the screen reader users I know use Facebook and Twitter either via the mobile sites or apps because of the inaccessibility. I don’t really frequent many other social networks so can’t comment on them.

      • tady 5:03 pm on February 14, 2013 Permalink | Log in to Reply

        This is one that caught my eye too. I wondered about the possibility of integrating an icon font? (An example would be: http://fontello.com/ ) Would this be more beneficial? In this case, the under “Font Awesome” there’s a pretty decent icon to logout. Couple this with an anchor title and it could be small/discreet enough to go alongside the “Howdy, username [Gravatar]” easily. I would envisage a (slow) update of all icons across the dashboard to an icon typeface over time, which would result in this being second nature or intuitive.

        As many of these font icons are actually unique entities (i.e. it’s not like the logout symbol replaces the letter “L”), maybe this is creating an element of greater confusion? Perhaps an image with a proper alt/title would be more effective?

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

          A small problem with using icons alone is that speech recognition users can sometimes find it difficult to action the link. Those users can usually access image links if they know what the alternate text is, but of course that is not always obvious.

          That said, in this case the alternate text would be very likely to be “log out” or “log off”.

          Speech recognition users do have other ways of activating links but they can get laborious.

          With icons there could also be the issue that they are not obvious enough for some users – maybe with cognitive impairments.

          • esmi 1:02 pm on February 15, 2013 Permalink | Log in to Reply

            A small problem with using icons alone is that speech recognition users can sometimes find it difficult to action the link.

            As an ex-VR user (try coding in Dragon for 6 months — it’s… interesting), I’m in two minds about this.

            Using Dragon as an example, if it is used with IE, all links on a page are given numbers within the browser so you can easily jump to a given link. As I’m a Firefox girl, I looked around for an FF extension that would give me similar functionality. So I’d argue that this really is an edge-case between the web page design and the user’s choices/software configuration. At worst, VR users should be able to TAB to any link in a page — so nothing should be ever completely inaccessible. And if an icon was used, it wouldn’t/shouldn’t be the link itself. The main link’s text would/should still be there to be used.

            • _Redd 2:29 pm on February 15, 2013 Permalink

              A friend and I were talking about this……

              1. WHAT exactly enables tabbing?
              2. Is the tabbing behavior consistent for screen readers, voice-recognition systems, and other AT?
              3.is it necessary to also add a:focus if you want the focus to be in sync with tabbing?

              I welcome any url links, authoritative sources, or insights on this. I know that between the two of us, we could not answer these questions between ourselves.

            • esmi 4:07 pm on February 15, 2013 Permalink

              1. It’s default browser behaviour. Just like web developers have HTML specs, browser developers have W3C User Agent specs that they need to follow.

              2. Pretty much, yes. Different AT might have their own inbuilt helper functionality (which, by & large, is outside of our remit as developers) but, by default, they should all fall back to the default tabbing behaviour.

              3. Yes. And if you want to support older version of IE (IE8 or below), you also need to apply the same styling to :active pseudo class.

              4. http://accessites.org/site/2007/05/keyboard-friendly-link-focus/

            • _Redd 4:37 pm on February 15, 2013 Permalink

              Awesome, thank you esmi from both of us!

      • GrahamArmfield 5:09 pm on February 15, 2013 Permalink | Log in to Reply

        I finished the plugin I was talking about the other day and after some initial teething problems it’s now available – through my own site initially but I intend submitting to WP plugin repository when I’ve worked out how I do that.

        The plugin places a Log Out link into the admin toolbar. I’ve tested it with Dragon Naturally Speaking and on an iPad and it seems to work OK.

        Originally I was attempting to get the Log Out link into the main menu – above the Dashboard link but I couldn’t get that to work properly.

        I’d welcome any feedback if people want to try it out – it’s available at: http://www.coolfields.co.uk/2013/02/wordpress-permanently-visible-log-out-link-plugin-version-0-1/

        • esmi 5:32 pm on February 15, 2013 Permalink | Log in to Reply

          Cool! Have you had a look at Plugin Submission and Promotion?

        • _Redd 7:55 pm on February 15, 2013 Permalink | Log in to Reply

          AWESOME!!! And so timely! Do you forsee any issues with multisite?

        • _Redd 2:56 pm on February 20, 2013 Permalink | Log in to Reply

          Good morning Graham, on one of my test sites (multisite set up) I have both yours and Joe’s plugin activated.

          So far, when I am “in” WordPress, the login and logout functions seem to be fine–however, one of the things I do is “View Page” to look at my work, and that opens in another tab.

          I get network access message errors when I try to log out through the “normal” logout screen on the new tab. I’m never sure if it’s an actual network problem, but you may want to check the function of the “standard” logout link, on a new tab, with the plugin installed.

          The difference between the logout message I get when I log out of a site WITHOUT the plugin activated is ……wp-login.php?loggedout=true

          The logout message I get when the plugin activated is….wp-login.php?action=logout&_wpnonce=e965affe42

          So it looks like processing a nonce may be the culprit

          That said, your plugin and Joes are some of the BEST are REAL progress for WordPress! Thank you thank you thank you!

          • GrahamArmfield 4:36 pm on February 20, 2013 Permalink | Log in to Reply

            Hello _Redd, thanks for the notes.

            To place the Log Out link in the toolbar I’m using the admin_bar_menu hook to call a function that calls the add_menu() function.

            One of the parms I’m passing is the link for the item which is provided by wp_logout_url(). I’ve left the redirect parm empty to allow the default processing. This seemed to me to be the safest way to get the appropriate link as I couldn’t track down the function where the existing logout links are added to the toolbar.

            This seems to be correct as per the guidance on the codex – notably: http://codex.wordpress.org/Function_Reference/wp_logout_url but if I’ve made a mistake I’d be grateful of any pointers to the correct way to generate a Log Out link.

            I have a test site without my plugin running and the existing Log Out link does include the reference to the nonce.

            • _Redd 4:53 pm on February 20, 2013 Permalink

              Thank you so much for the rapid response….a lot for me to learn from, personally, and a lot for me to chew on. And sadly, much is of this is over my head. I’m like a monkey looking at the back of a watch with a lot of this stuff! But! I’ll review the links you’ve provided, revisit this and get back with you for the results…..it might be a couple of days, but will definitely revisit.

              Thanks again!

    • George Nilsen 1:08 pm on February 14, 2013 Permalink | Log in to Reply

      I canot get access directly from http://myvikingdomain.com but can’t get more than ‘you had a typo’–which worked ONLY once. Now I have to go from a ’1 result’ menu (w/o seeing the result) by clicking on the ‘fb’ icon(linked to the domain) to get access. How can anyone get there to read my posts & pages, market my books?

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

      @George Nilsen: Sorry? I don’t follow you…

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

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

      Already on it. :)

    • esmi 3:23 pm on February 18, 2013 Permalink | Log in to 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.

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