Make WordPress Accessible

Updates from April, 2013 Toggle Comment Threads | Keyboard Shortcuts

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

    IRC Meeting: April 24, 2013 

    We had another lively IRC meeting on Wednesday.

    3.6 Post Formats

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

    (More …)

  • Andrew Nacin 5:53 pm on April 23, 2013 Permalink
    Tags: attributes,   

    Post titles in attributes 

    In pretty much every theme, there is something that looks like this:

    <a href="<?php the_permalink(); ?>" title="<?php echo esc_attr( sprintf( __( 'Permalink to %s', 'twentythirteen' ), the_title_attribute( 'echo=0' ) ) ); ?>" rel="bookmark"><?php the_title(); ?></a>

    My question: Is “Permalink to (title of post)” a WordPress anachronism that, by being a redundant title attribute, actually harms accessibility?

    • Joe Dolson 5:59 pm on April 23, 2013 Permalink | Log in to Reply

      Yes, that is generally not helpful to accessibility. The amount of harm is relatively slight (that vast number of title attributes in nav menus is a greater issue), but it is definitely an anachronistic model that causes minor accessibility issues.

      Essentially, any case where the title attribute is the same as the link text, it is redundant at best, and causes a repetition effect (where screen readers read the text twice) at worst.

    • Graham Armfield 6:02 pm on April 23, 2013 Permalink | Log in to Reply

      I agree with Joe.

    • Lance Willett 6:31 pm on April 23, 2013 Permalink | Log in to Reply

      Note that not all themes duplicate the post title—for example, in Twenty Thirteen we use this format for title text to go along with anchors where the anchor text is the post date, and in that case it’s very important for usability and accessibility both.

      • Joe Dolson 7:04 pm on April 23, 2013 Permalink | Log in to Reply

        Yes – but that’s a different use case, where the anchor text *does not* match the title attribute. In that case, the problem is that the title attribute will usually not be available to users of assistive technology, because title attributes are not exposed by default in most non-mouse-based contexts.

        This is also the reason that the title attribute problem is relatively minor — title attributes are only perceived by a screen reader user if a user is using verbose settings for reading those attributes, which, due to the fact that title attributes are, on the whole, not usually helpful, is commonly disabled.

    • esmi 7:15 pm on April 23, 2013 Permalink | Log in to Reply

      It’s also of absolutely no use to sighted keyboard navigators. Given that some of these users will be dyslexics using screen readers, it may well be that the announcement of the title attribute will be causing more harm than good. I’d argue that, as a very general rule of thumb, if it’s important enough to be added to a page, it should be added in clear text. If it’s not that important, why bother adding it anyway?

    • ryanve 10:25 pm on April 23, 2013 Permalink | Log in to Reply

    • joe 4:17 am on April 24, 2013 Permalink | Log in to Reply

      Although Joe Dolson is right, that it has minimal effect, I think esmi raises a good point in that anything that requires mouse activity to expose, and that exposure is important, it should be surfaced in a more inclusive manner.

  • Joe Dolson 3:28 am on April 21, 2013 Permalink
    Tags: , , patch   

    Just submitted: https://core.trac.wordpress.org/ticket/24148. Comments welcome.

    • _Redd 12:13 pm on April 22, 2013 Permalink | Log in to Reply

      I never cease to be amazed, Joe, thank you–yet again.

      I looked briefly at the ticket, and I see obenland has the following question:

      Do we really need additional html elements for the ids? Can’t the labels or the p elements carry them with the same effect?

      My understanding is that ARIA is needed above and beyond simple form labeling and p elements due to the dynamic nature of WordPress. In other words, if a page is updated dynamically for whatever reason, the screen reader will only capture the “old” information in the buffer, without ARIA…

      Is the following a true and correct statement?

      To create a “live” region by which screenreaders may be able to access dynamically updated pages (such as those used in WordPress) using the aria-live property is necessary–simple form elements won’t do.

      Thanks for any input you may have, and thanks again, VERY much, for what you do.

      • Joe Dolson 2:07 pm on April 22, 2013 Permalink | Log in to Reply

        First, this is *not* creating a live region — the native comment form is not a dynamically updated region; although some themes may cause it to be. What this patch is about is incorporating the extra text statements that are contained within the comment form into the labels for the elements that they are associated with using ARIA, so that text is exposed to a screen reader without requiring a second pass through the form.

        The commenter is correct that an extra HTML element is not required in order to attach these IDs; and I was able to eliminate two of them, because the text they’re catching is already wrapped in entirety. A third span is required because the text I needed to catch is not already discretely wrapped by any element.

        Your statement is accurate, yes — but not actually relevant to this situation.

    • andyvaughn 9:02 pm on April 22, 2013 Permalink | Log in to Reply

      Thanks for the thorough look at this, Joe.
      Perhaps this is forest-questioning in a tree-analysis area…but, is it semantically appropriate to be using paragraph-tags for comment-form-email, comment-form-comment, and comment-notes? I always rewrite my comment templates to definition lists, with labels as definition-titles, and inputs/textareas as definition-descriptions, as I felt this was more semantically correct. Am I incorrect? Does this have a negative effect when read as a definition-list? It’s been a while since I’ve used a screen reader.
      Either way, thanks for the work Joe.

    • esmi 9:48 pm on April 22, 2013 Permalink | Log in to Reply

      I don’t think there’s a problem – semantically – with either approach and there are valid arguments for both. From a Real Life accessibility perspective, it might be worth bearing on mind that some (most?) screen reading software will announce content in definition lists in the same manner as content in paragraph tags. So from the user’s perspective, there’s no difference and your definition lists will still work just fine.

      • andyvaughn 9:52 pm on April 22, 2013 Permalink | Log in to Reply

        Thanks for the quick reply, Esmi. It helps to know I’m not causing screen-reader confusion with my preferred form markup.

    • Joe Dolson 9:52 pm on April 22, 2013 Permalink | Log in to Reply

      I’d agree with esmi on this; there may be some semantic value to considering these to be definition lists (although it’s debatable), but there is no accessibility value. It would just be a matter of your own judgement concerning whether the list of inputs should be considered a set of term/definition value pairs. My feeling is that the

      Either way, it doesn’t impact accessibility.

    • Anders Herning 11:16 am on April 24, 2013 Permalink | Log in to Reply

      Awesome work Joe! Really appriciate it! I know it’s not the right approach, but I gotta ask:
      I’ve been searching for the most “popular” accessibility theme for WordPress but can’t seem to find any.
      Do you have any advice on this?

  • Joe Dolson 6:28 pm on April 16, 2013 Permalink  

    Updated Theme Review Guidelines 

    I’ve updated the Theme Review guidelines for Accessibility again. This update takes into a consideration a number of suggestions and questions from Chip Bennett regarding the understanding of issues and how to resolve them.

    Among the changes:

    • Images now state that decorative images must be included with CSS.
    • Headings explicitly states that post and widget titles must be wrapped in headings, to draw the ‘reasonable headings’ guidelines into a context explicitly relevant to WordPress structure as defined by a theme.
    • Link text provides specific techniques for accomplishing the goal.
    • Keyboard navigation provides guidance on testing and specific mention of one of the most common failures for dropdown menus.
    • Contrast references tools for testing.
    • Skip links defines a conforming skip link.
    • Forms defines specific changes that can be made to defaults that would break accessibility.

    Your comments are welcome.

  • esmi 11:01 am on April 11, 2013 Permalink  

    Support Requests 

    If you post a comment here looking for support regarding your own site, it will be deleted. If you need support, please post on the wordpress.org support forums.

    Thank you.

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

    Accessibility IRC Chat – 3rd April 2013 

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

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

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

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

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

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

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

      RUN WITH IT! Enhancements are for plugins!!!

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

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

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

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

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