Make WordPress Accessible

Tagged: core Toggle Comment Threads | Keyboard Shortcuts

  • Joe Dolson 9:38 pm on January 24, 2016 Permalink
    Tags: core, , standards   

    Accessibility code standards for WordPress in draft 

    The accessibility code standards for WordPress have been added to the core handbook and are open for feedback over the next two week. Also see the Core blog announcement and the draft standards themselves!

  • Joe Dolson 7:46 pm on April 27, 2015 Permalink
    Tags: 4.3-early, core, priorities   

    Accessibility Priorities for 4.3 

    For the development of WordPress 4.3, we’ve got a handful of major issues we want to work on to create a smoother and more predictable experience for users with disabilities.

    Reconcile Heading hierarchy throughout admin & clean-up heading contents

    #31650: Missing H1 headings in admin (fixed)
    #26601: Inappropriate content in headings on admin screens.

    Use Semantic elements for non-link links

    Tracking ticket: #26504
    Individual tickets (so far): #31487, #31476
    Related: #26550

    Reconcile search methods

    WordPress incorporates 5 different search interactions in the admin. For usability, accessibility, and maintenance reasons, this should be made more uniform. We’d like to see this reduced to two basic interactions.

    #31818 Uniform Search Form Display/Experience

    List table issues

    We gathered a ton of data on the List table navigation experience during 4.2, and those are being turned into tickets.

    #32028 List table pagination: text improvements for screen readers (fixed)
    #32150 List table: better indication for “no taxonomy” (fixed)
    #32152 List table: Comments column accessibility improvements (fixed)
    #32147 List table: headings for pagination and views links
    #31654 List tables: Select All shouldn’t be a column header (fixed)

    Color contrast issues in admin:

    #31548, #31713, #28599

    Improve editor experience:

    The editor is the single most frequently used part of most WordPress installations – and the experience with this interface should be more consistent.

    #29838: Editor focus order issues.

    Throughout the cycle, we’ll also be picking away at the dozens of other smaller tickets we want to fix, but these are large issues that will have a deep impact on WordPress, and will require a community effort to make progress.

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


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


      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.

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

      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.

      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.

      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

      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:

        position: relative;

        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.

compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help
shift + esc
Skip to toolbar