Make WordPress Accessible

Updates from January, 2015 Toggle Comment Threads | Keyboard Shortcuts

  • Rian Rietveld 7:38 am on January 31, 2015 Permalink

    Theme Switcher: Accessibility test result 

    Accessibility test results of the new Customizer Theme Switcher

    Customizer Theme Switcher Beta Version 0.7
    On WordPress 4.2-Alpha nightly build

    @afercia (keyboard, screen-reader, code review, report)
    @trishacupra (keyboard)

    The report is divided into:

    • Must have
    • Nice to have
    • General Customizer issues
    • A11y unrelate issues

    Must have

    1. The accordion title

    The accordion title doesn’t convey enough information about the purpose of this section. The text just says, for example:

    Theme: Twenty Fifteen
    Press return or enter to expand

    OK, that’s nice to know… but what I can do there when it’s expanded?
    Text should say also something like “preview more themes” or similar. This is a UI issue for all users: I just clicked on “Customize”, I know I’m in a place where I can customize things. So what I understand is I can “Customize Site Title & Tagline”, “Customize Colors” etc. and for analogy with other titles the information I get here is that I can “Customize Theme: Twenty Fifteen”. Nothing about a “preview”.

    2. Empty tab stop after “Add New” and before search.

    Just on first load, ‘.theme-overlay’ has display: block meaning is visible (though empty) AND is focusable:

    <div class="theme-overlay" tabindex="0"></div>

    Empty tabs stops are confusing for users, they can’t figure out what’s in there. What happens after you open and then close the modal? fadeOut() sets display to none and ‘.theme-overlay’ is no more focusable: no more empty tab stop. Should be display: none also on first load, to avoid the empty tab stop.

    3. Missing label

    #themes-filter “search installed themes…” has no label

    4. Focus + Enter on “Theme Details”

    Focus + Enter on “Theme Details” doesn’t trigger the details modal.

    Everything must be operable with a keyboard.
    Elements need to be focusable to receive keyboard events. Why binding keydown event on ‘.theme-screenshot, .more-details, .theme-name’ when they’re not focusable. No focus, no keydown event. What about to bind keydown directly on ‘.theme’ which is already focusable? And then move ‘.theme-actions’ out of ‘.theme’ and position it absolutely?

    5. ARIA role and aria-label on the details modal

    ARIA role and aria-label on the details modal, to give feedback a modal is currently open.

    <div class="theme-overlay" tabindex="0" role="dialog" aria-label="<?php esc_attr_e( 'Theme details' ); ?>"></div>

    This way, when the modal opens, screen reader will read out:
    “Theme details dialog”
    Without this, screen readers will start reading out all the content of the dialog, with no feedback about a dialog is actually open, e.g.:
    “out of list” (meaning it’s exiting from the themes list)
    “Show previous theme button, Show next theme button, Close overlay button, Twenty Fourteen Version: 1.3” etc…

    Important: to be done together with point 2.

    6. Close button.

    For consistency with 5., change the close button text in ‘Close details dialog’.
    Current text ‘Close overlay’ doesn’t help me to understand what an “overlay” is, that’s developers language.

    7. Contain keyboard navigation inside the modal.

    When a modal is open, keyboard navigation must be contained inside the modal.

    WordPress already does this for almost all of its modals. Every modal has its own way… we should standardize this sooner or later.
    We can provide a working code example, not a real patch, we’ve just patched the plugin locally. Code borrowed from media-views “wp.media.view.FocusManager”.
    It’s just an example, this feature can be implemented in many different ways, see for example other modals (wplink, etc.). Little concerned about jQuery UI :tabbable performance, maybe not an issue.

    8. The preview <iframe>

    The preview <iframe> should have a title attribute.

    9. Focus on Add New Theme box

    Focus on Add New Theme box (the last one in the left sidebar). Recommended: make focus style same as hover.

    Nice to have

    10. Tabbing in the modal

    Tabbing in the modal, there’s no easy way to find information about the theme! for example in this text:

    Twenty ThirteenVersion: 1.4
    By the WordPress team

    only “the WordPress team” is a link, when read out of context has no useful meaning. Would be nice to have some more text in the link (maybe using screen-reader-text) with the current theme name. Needs .org API change?

    11. Collapse/expand link

    Tester’s report: “Can’t figure out how to navigate to the ‘expand’ arrow after collapsing the customizer.”

    Important: when the sidebar panels slide out and are out of view, they’re still focusable and “tabbable”. You can tab through them and also activate their controls, just focus one of them and press Enter.

    Recommended: when panels slide out and their animation ends, they should really be hidden with display: none to make their controls not focusable.
    Similar to what currently happens in media views, see: #30599

    12. Collapse/expand link focus style

    Improve the collapse/expand link focus style

    13. Jump from the sidebar pane to the preview pane

    Consider having some sort of mechanism to quickly jump from the sidebar pane to the preview pane and vice-versa.

    Say you’re a keyboard user, you choose a theme and you press Enter on the “Live Preview” button. Page is updated and focus is lost. To navigate with the keyboard to the preview pane, you have to tab through all the sidebar controls first.
    Same when you want to return to the sidebar pane after finally getting to the preview pane.

    Tester’s report: “Can’t find a way to skip straight across to the theme preview pane on the right in order to explore the new theme preview, scroll up and down to check out the theme, etc.”

    Important note:

    Say you choose a theme and finally tab to the preview pane: there’s a chance you’re previewing a totally inaccessible theme.
    Tester’s report: “You’re tabbing and you have no idea where you’re in that case.”
    As a screen reader user you may be totally lost, as a keyboard users you could fall in some keyboard trap.

    Recommended: add a way to easily exit the preview pane and move focus back to the sidebar.

    14. Giving focus to iframes. (related to 13)

    Some browsers, especially when in combination with some screen readers, have issues giving focus to iframes.

    Tester’s report: “When I tab between the Collapse link and the Preview pane, there isn’t a smooth transition, which is the ‘gap’ where I’m getting lost. I suggest a link that appears on focus to go to the Preview pane just before the Collapse link.”

    General Customizer issues

    15. The .theme-screenshot image

    The .theme-screenshot image in “You are previewing” accordion section needs an alt attribute, see customize.php

    <img class="theme-screenshot" src="<?php echo esc_url( $screenshot ); ?>" />

    16. Headings

    Missing first level heading. todo check header hierarchy.

    17. Orphaned/misplaced label, examples

    “Background Color” (and all the ones for picking colors with Iris)
    there’s a label that wraps 2 input fields, one gets revealed when picking a color. We understand this is how iris works, BTW screen readers won’t get the association between the label and a form element.

    “Background Image”:

     <label for="background_image-button">
     <span class="customize-control-title">Background Image</span>

    The “background_image-button” button is the “Change Image” button.
    Result: click on what appears to be a title: “Background Image” and a modal opens.

    18. Empty links (Customizer or underlying panes?)

    Several empty links (some of them maybe img without alt? some just empty). See several add widget toggles a.widget-action with no text or aria-label, just empty. They should have some text that makes sense also when read out of context.

    19. Buttons

    Buttons should be buttons (see primary button is an <a>).

    20. Color contrast

    Color contrast: active/focus state, accordion toggle arrows, etc.

    21.  .theme-overlay .theme-version has user-select: none;

    Why .theme-overlay .theme-version has user-select: none; ?
    As a user, I want to be able to select that text.

    A11y unrelated

    22. Attributes

    Attributes should be escaped? see e.g.
    placeholder=”<?php _e( ‘Search installed themes…’ ); ?>”

    23. <button> elements

    All the <button> elements need type=”button”.

    24. Event namespaces

    Consider the use of event namespaces?

    25. “Update Available”

    On hover,the cursor is a pointer but clicking it doesn’t do anything: consider using default cursor style

    26.  Maybe .theme-header should not be rebuilt on each prev/next

    Enhancement: maybe .theme-header should not be rebuilt on each prev/next ?
    With .theme-header being “fixed”, focus would not be lost on each prev/next action, this would save focus handling via JS.

    27. Bug in Chrome when focusing the close button.

    Couldn’t reproduce using Firefox, looks like it happens just in Chrome.
    See attached screenshot: as soon as you tab on the “Close” button, the sidebar pane underlying the details modal slides out and the main accordions gets in.

    See: .wp-full-overlay-sidebar-content
    it inherits overflow: auto from theme.css so it can scroll horizontally.

    When focusing any focusable element on the right side of the details panel (close button or links in the content) it will scroll thus moving the sidebar on the left.

    Notice it gets also overflow-y: auto and overflow-x: hidden from customize-controls.css
    Need to reset both to visible, just when the details modal is open, using something like:

    .modal-open .in-themes-panel #customize-controls .wp-full-overlay-sidebar-content {
    overflow: visible;


    customizer theme switcher tabbing

    customizer theme switcher tabbing

    • Drew Jaynes (DrewAPicture) 7:59 am on January 31, 2015 Permalink | Log in to Reply

      Thank you @afercia, @trishacupra, and @rianrietveld. Very thorough!

    • Graham Armfield 3:41 pm on January 31, 2015 Permalink | Log in to Reply

      Amazingly thorough test. Excellent work.

    • Joe Dolson 3:47 pm on January 31, 2015 Permalink | Log in to Reply

      This is great data – thanks for doing this!

    • Nick Halsey 7:08 pm on January 31, 2015 Permalink | Log in to Reply

      Thanks for the detailed & thorough testing! I’ve popped into #accessibility on slack and will work through these issues today. Many of these issues require core patches; I’ll create tickets for those and patch them (although I may leave some as good-first-bugs); it would be great if a committer could follow up on those soon.

    • Nick Halsey 8:45 pm on February 1, 2015 Permalink | Log in to Reply

      Please let me know if any of these changesets look incorrect in any way. Working my way through the list from the top, will do a second pass to create the core tickets that I know the fix for.
      1. todo
      2. Fixed in https://plugins.trac.wordpress.org/changeset/1080258/customizer-theme-switcher
      3. Fixed in https://plugins.trac.wordpress.org/changeset/1080261/customizer-theme-switcher
      4. Sorry, I completely messed that up trying to fix something else. Fixed in https://plugins.trac.wordpress.org/changeset/1080271/customizer-theme-switcher
      5. Fixed in https://plugins.trac.wordpress.org/changeset/1080272/customizer-theme-switcher
      6. Fixed in https://plugins.trac.wordpress.org/changeset/1080274/customizer-theme-switcher
      7. todo
      8. todo core ticket/patch
      9. todo core ticket/patch (this uses the CSS from the admin page)
      10. This would be a core patch at least, and possibly an API change. Could you create a ticket for this issue on core trac targeted at the current admin themes page, which has the same issue, which would most likely also fix the plugin?
      11. I think #29949 would probably fix this?
      12. I think that’s likely to change with #31195 if that happens, but in the meantime #31201
      13. todo core ticket/patch, I’d like to add “Skip to preview” and “Back to controls” `.screen-reader-shortcut` links
      14. Add to 13. ticket an additional preview link before collapse
      15. The proposal is to make that section go away in the merge patch, so should be a non-issue.
      16. todo core ticket/patch #customize-info .accordion-section-title should probably have a h1 somewhere?
      17. todo core ticket/patch please open a ticket with more specifics on issue with the different control types (upload/image, color, etc.)
      18. todo core ticket/patch please open a ticket with more specifics on this issue
      19. todo core ticket/patch please open a ticket with a list of buttons that aren’t buttons in the Customizer so we can fix those (I know widgets have several)
      20. See #29158. Would love to get that resolved, it’s really bad right now.
      21. todo core ticket/patch (no idea why that’s there)
      22. Fixed in https://plugins.trac.wordpress.org/changeset/1080352/customizer-theme-switcher
      23. Fixed in https://plugins.trac.wordpress.org/changeset/1080362/customizer-theme-switcher. Could also use a core ticket/patch for the existing equivalent for the admin page
      24. Not sure that that’s needed since everything’s already scoped to the Customizer section/control, but I’m open to suggestions/patches.
      25. I decided to remove the updates UI entirely, it doesn’t fit here. https://plugins.trac.wordpress.org/changeset/1080335/customizer-theme-switcher
      26. Could get a bit messy since there’s no container element for to sibling elements to .theme-header, is there a specific benefit here other than saving some JS?
      27. That’s been bugging me for a while and I had no idea what was causing it, thanks for the fix! https://plugins.trac.wordpress.org/changeset/1080369/customizer-theme-switcher

    • Nick Halsey 9:40 pm on February 1, 2015 Permalink | Log in to Reply

      Core tickets:

      I left some as good-first-bugs. I didn’t make tickets for ones where I’m not sure of exactly what’s needed.

      8. #31202
      9. #31203
      12. #31201
      13-14. #31204
      21. #31205

    • Andrea Fercia 11:24 pm on February 1, 2015 Permalink | Log in to Reply

      Nick thanks very much for your complete review and fixings. Seen many of them are already in v. 0.8.

    • Sharon Austin 3:06 pm on February 2, 2015 Permalink | Log in to Reply

      This is a superb report. I’m learning a lot just by reading it, because the report spells out “why” something is broken for the user, not just what is broken. I hope to see more reports like this.

    • Andrea Fercia 6:50 pm on February 3, 2015 Permalink | Log in to Reply

      Noticed two new issues, then we should maybe review all the points and do a second testing round:

      • DIVs added as last items inside UL (see the famous add-new-theme div+link) that’s not just invalid code but also not semantic and problematic for a11y: that list should… list 🙂 the themes. Add new theme link is a control logically separate by the list and should be outside of the list
      • implicit labels (the ones without “for” attribute that just wrap an element) that contain more than one element so UAs won’t understand which element they’re associated to
      • “Search installed themes” gets read out twice. Repeating the same text in the label and in the placeholder it’s not a so good practice. Placeholder should not be used as a label but as a “hint” about how/what to enter in the field.

      Edited: added 3rd new issue.

    • Andrea Fercia 7:36 pm on February 12, 2015 Permalink | Log in to Reply

      Reviewed all the issues, thanks to @celloexpressions dedication to accessibility the main ones are fixed. Big thanks 🙂 There are some outstanding issues, listed below. Note: Nick, will report also some of your comments, for clarity:

      New 1.
      “add-new-theme” DIV added as last items inside UL: invalid/non semantic code, also problematic for accessibility: how many themes in the list? Add new theme link is a control logically separated and should be outside of the list.

      New 2.
      “Search installed themes” gets read out twice, at least with NVDA. Repeating the same text in the label and in the placeholder it’s not a good practice. Placeholder should not be used as a visual label but as a “hint” about how/what to enter in the field.

      Old 1. The accordion title doesn’t convey enough information about the purpose of this section.
      see https://make.wordpress.org/core/2015/02/03/customizer-theme-switcher-update-22/
      > Our biggest remaining decision is whether to change the title of the “themes” section in the Customizer.
      Note: there’s ongoing discussion about the header area, involving possible UI changes.

      Old 10. Tabbing in the modal, there’s no easy way to find information about the theme!
      > This would be a core patch at least, and possibly an API change. Could you create a ticket for this issue on core trac targeted at the current admin themes page…?
      Thinking about this, not sure what we can do here about “authorAndUri” returned by wp.org API, there are also translation issues to take into consideration.

      Old 15. The .theme-screenshot image in “You are previewing” accordion section needs an alt attribute
      > The proposal is to make that section go away in the merge patch, so should be a non-issue
      OK, just mentioned here as a reminder.

      All the other issues already have a ticket or they’re not strictly related to the Customizer Theme Switcher, but to the Customizer itself, will open new tickets.

      • Nick Halsey 4:47 pm on February 13, 2015 Permalink | Log in to Reply

        1. unfortunately we can’t change that. The way the Customizer works, all controls need to be children of the same container, in this case the ul. We could put the add-new div within an li, though, if that would be better.
        2. So can we remove the screen-reader-text label then? We’d want that text in the placeholder only by default, but if we need to do anything additionally for accessibility let me know.

  • Rian Rietveld 1:41 pm on January 27, 2015 Permalink

    Test Chat Summary, January 26 

    After a few months of having a test session on Monday’s we gathered a group of people discussing and fixing tickets and patches.
    But limiting the testing to a weekly one hour session turns out to be not pracical.

    Not eveyone has the time to be there and work on that exact hour, we are a global group.
    @afercia is doing a ton of work on the tickets at the moment and we need more testing and more feedback.

    So here’s a proposal for making better use of our time, coders and testers.

    The Monday session will be a meeting to discuss the tickets/patches, like:

    • what are tickets we need to work on, what has priority
    • what tickets have a working, tested patch and needs dev feed back or assigned a milestone to
    • what tickets need to be tested and on what AT and who can we ask for that
    • what are the test results, and can we change / approve a patch
    • people can ask for functionally to test or ask questions on how to fix stuff

    Then after/during the test session we can install a patch on the test server in the trunk website and assign testers.
    During the week the testers can look at the changes and report back as a comment with the ticket or to the #a11y team in slack or by e-mail. Then everyone can test in their own time, we can give specific small tasks to test.

    We can also ask the testers to look at specific functionality in the current version of WP to find what’s wrong or needs to be changed.

    In this meeting we discussed:

    Ticket #28599 (Better Visual Focus Indication in Admin Menu): This ticket has a working patch and needs dev and designers feedback. @ryan will also take a look at it this week. In it’s current state the patch is’t ready for production, for example it misses all the parts related to color schemes and SASS.

    Ticket #30589 (Comments navigation template tags): We discussed if the landmark <nav> is appropriate for the comment navigation, <nav> is meant for main navigation. Now there is a risk that we overload a theme with nav’s @afercia will respond to that ticket with outline examples in Twenty Fifteen.

    Ticket #29955 (Section 508 issues found on WordPress 4.0 admin page): This ticket will be closed and divided it into new separated tickets.

    The patch on the test server this week will be for Ticket #28599 (Better Visual Focus Indication in Admin Menu). If you want to join in the testing, please contact @rianrietveld.

    Screen Reader Text support:

    This is an ongoing discussion and commented on by some of us in:

    In the codex WordPress Generated Classes there is an example on how to implement the screen-reader-text class. We advice to remove the


    because they have no use in this context. Just keep the focus.
    Clip is due to be deprecated in favor of clip-path, but clip-path is not very well browser supported yet. So lets stick to clip for the time being. Maybe a note of that in the codex will be useful.

    @joedolson will discuss a11y with @drewapicture this week, we also hope to get more dev feedback on some of the patches.

    In the weekly Accessibility Chat next Wednesday we want to discuss ticket priority.

    • Andrea Fercia 2:42 pm on January 27, 2015 Permalink | Log in to Reply

      To clarify just a bit my opinion, <nav> should be used for “major navigation blocks”. So yes, I do think there can be more than one <nav> on a page but what’s exactly “major” is matter of discussion.
      Specifically for comments, my opinion is that comments are by definition an “aside” or maybe a “section” as in the W3C example. They’re not the “main” content, they’re related to it. They’re complementary content. So if you add navigation to a “secondary” content, then considering that navigation “major” doesn’t look right to me.

    • هاست 9:56 pm on January 30, 2015 Permalink | Log in to Reply

      thank you

  • Joe Dolson 8:15 pm on January 26, 2015 Permalink
    Tags: commhub, poll   

    Community Hub Poll 

    If you haven’t seen it yet, please take a quick break to fill out the Community Hub poll. The poll closes at midnight on January 29th, so act quickly!

  • Joe Dolson 8:46 pm on January 15, 2015 Permalink  

    Better Support for Accessibility Issues 

    The support team’s weekly meetup today invited representatives from the Accessibility and Theme Review teams to share information about how we could better support each other. As a result of that meeting, we’ve officially agreed on the use of ‘a11y’ as the tag for accessibility issues in the Support forums.

    In the support forums, anybody can add tags to any thread – so if you see a thread that requires a11y help, be sure to add the tag so that people who monitor accessibility issues can easily find it.

    In parallel with this, anybody who’s interested in helping out on the support end of WordPress accessibility issues, you can monitor the accessibility tag to watch for new issues. You can check that page periodically, or you can subscribe via RSS or email.

    If you’ve got experience with accessibility and any of the other areas of WordPress information, helping out in the support forums is a great way to get started making a difference.

    For more information on WordPress support and tagging, here are a couple relevant resources:

    • Andrea Fercia 9:58 pm on January 15, 2015 Permalink | Log in to Reply

      ahem the link to “weekly meetup today” is not a link 🙂

    • Joe Dolson 9:59 pm on January 15, 2015 Permalink | Log in to Reply

      Grah. Forgot to paste it. (I copied it…just didn’t finish the process!)

    • Rian Rietveld 2:49 pm on January 16, 2015 Permalink | Log in to Reply

      Maybe it’s also a good idea to check all the accessibility and accessible tags and decide if they need to be removed or changed into a11y tags, then we have the lot together

    • Joe Dolson 4:02 pm on January 16, 2015 Permalink | Log in to Reply

      Anybody can go in and add a11y tags to any support post that needs it; there’s no particular need to remove other tags. All registered WordPress.org users can add tags, however.

    • Rian Rietveld 6:56 pm on January 26, 2015 Permalink | Log in to Reply

      Was just wondering how people asking support know they can use the a11y tag as preferred before accessibility and accessible

    • Joe Dolson 6:58 pm on January 26, 2015 Permalink | Log in to Reply

      They don’t; but that’s intentional. The idea is that forum moderators can add the tag when it’s necessary, so that people who are accessibility specialists can find the info.

  • David A. Kennedy 5:08 am on January 15, 2015 Permalink

    WordPress Theme Pattern Library for Accessibility 

    We want to make creating accessibility-ready themes as easy possible. To do that, we’re working on building a library of accessible patterns for themes. That way, theme authors can learn about and implement accessibility in their themes with ease.


    The goals are simple:

    • Become a central resource for WordPress theme developers to learn about and how to implement accessible patterns for accessibility-ready themes.
    • Patterns should be self contained and have as few dependencies as possible.
    • Be a codebase that gets tested rigorously, evolves constantly and keeps it simple.

    Pattern Ideas

    I have a handful of pattern ideas that should be included, most of which help meet the current accessibility-ready requirements. This isn’t an exhaustive list, of course, and other patterns would be needed and welcomed.

    • Skip link (in Underscores)
    • Mobile menu toggle (in Underscores)
    • Menu drawyer, expand from side
    • Menu overlay
    • Continue reading links (in Underscores, partly)
    • Form label and field patterns (start with Core markup and expand on that.)
    • Outline/:focus style examples
    • Tabs
    • Accordion


    After feedback from the Accessibility team, especially in a recent meeting, I think the best way to implement is:

    • Giving each pattern its own repository: Each pattern (including whatever HTML, CSS, JS and PHP needed) would be in a self-contained repository under this Github organization. Theme authors could just download the repos, drop in the code and go.
    • A page that explains the different patterns and their purpose. This would probably be a page in our future handbook or on our Make site.
    • A link to a demo. Showing the working pattern would be nice, but not a requirement. I would like to see different patterns created first before we worry about this aspect. To me, this comes later.

    What’s Next

    This is only a rough list of basic steps:

    • Start working on patterns needed for accessibility-ready themes.
    • Establish a code contribution policy.
    • Develop a testing policy.
    • Test patterns as they get created.
    • Release patterns.

    We can release one pattern at a time really, as we create and test them.


    I have an idea for a pattern. Can I work on it? Yes, just let me know in the comments, so I can keep track of who’s doing what and make sure we don’t have people working on the same pattern. That way, I can connect people for collaboration.

    How do I get access to the WPAccessibility repositories so I can commit code, etc.? You should develop the pattern on your own Github account or locally first. Once I have a list of patterns being worked on, we’ll create repositories for them and go from there. We will likely adopt the fork and pull method.

    What about theme frameworks? Can I submit a pattern for it? Yes, we’d like to cover as many methods of theming as possible.

    Can I include Sass, Less, Grunt, Gulp, build tool, etc.? For now, please create patterns with as few dependencies as possible. Accessibility can be intimidating and we want keep the barrier to entry as low as possible.

    If you want to be involved, make sure you’re following this blog. You’ll see updates here. If you have other ideas or questions, let us know in the comments.

    • Jeff de Wit 10:51 am on January 15, 2015 Permalink | Log in to Reply

      Nice. I like it.

      Most of the stuff I do at work is with Genesis, and I can definitely get some patterns worked out for its hooks (skip link specifically).

    • Joe Dolson 4:06 pm on January 15, 2015 Permalink | Log in to Reply

      One pattern I’d like to see added is a form feedback pattern using AJAX and aria-live regions. This could be used for enabling a live search or doing instant feedback on submitting comments, and would be very valuable. (I can work on that, too.) Thanks for running with this, David!

    • MRWweb 7:09 pm on January 15, 2015 Permalink | Log in to Reply

      This might be too big or too hard to write a universal pattern for due to varying theme file structures, but some type of theme heading structure pattern would be awesome. I’m just not sure how it would look.

      • David A. Kennedy 3:00 am on January 22, 2015 Permalink | Log in to Reply

        I do think this would be hard to do – simply because to really understand a theme’s heading structure, you need to see the whole theme. These would just be patterns – bits and pieces.

        But this is a good idea, and perhaps we can beef up our recommendations in the theme accessibility requirements. That might help. Thoughts, @joedolson?

    • Chrisdc1 12:51 pm on January 16, 2015 Permalink | Log in to Reply

      Some themes have it already (especially the Twenty * series), but would a simple implementation of tabable drop down menus be useful? I’ve got a pull request about this for _s that’s turned into a bit of a monster thread, but I could make something easy to drop in for standard menus (with or without jQuery).

    • Andrew Woods 9:47 pm on January 16, 2015 Permalink | Log in to Reply

      Someone else had a similar idea. I found this site a few months ago. http://a11yproject.com/patterns/

      • David A. Kennedy 3:03 am on January 22, 2015 Permalink | Log in to Reply

        I’ve seen these. They’re great, and could definitely serve as inspiration or something we can fork. Thanks for the suggestion!

    • Tomas Mackevicius 4:11 am on January 19, 2015 Permalink | Log in to Reply

      These are general HTML/CSS/JS patterns, we need patterns that are adapted for WP.

    • Tomas Mackevicius 4:21 am on January 19, 2015 Permalink | Log in to Reply

      It would be nice to have patterns to replace headings that are hard-coded in the WP core. (Ultimate solution would be create function options to make it easy to replace them)

      When you’re creating theme, you pick your document structure style (eg. one H1 vs multiple H1, etc.). In some cases hard-coded headings will not be a good fit for the envisioned document structure like in my example.

      In my case I’m looking for the function to replace H3 heading for the #reply-title. I found one, but I do not have very big experience to evaluate it if it is good, if it doesn’t have any security issues, etc.:


      If anyone has solution, or could evaluate that function, we would have one snippet ready for the library 🙂

    • Joseph Karr O'Connor 11:25 pm on January 21, 2015 Permalink | Log in to Reply

      Tomas Mackevicius: I approved your comment but my avatar and id were attached to it. Regrets.

  • Joe Dolson 8:09 pm on January 7, 2015 Permalink  

    Accessibility Ticket Priorities for WordPress 4.2 

    Here we are again, at the beginning of another great rendition of WordPress! As is normal at the beginning of a cycle, here are a few big issues that the WordPress Accessibility team would like to see focused on at this stage. These are mostly large areas where usability and accessibility need some concerted effort, in addition to some major decisions that need to be pinned down.

    Media Library

    The media library views have gotten a lot of good work recently, but there’s still a long ways to go. And it’s not just accessibility that’s needed here, but also some general usability questions for all users, as pointed out by Ryan Boren. Some work needs to go into the flow for all users; while all features need to be available via keyboard, it would be nice to explore a user flow that allows the work flow to be smooth, as well.


    • #30512 – Improve media views accessibility
    • #30599 – Media views: improve keyboard accessibility avoiding confusing tab stops
    • #28820 – Focus isn’t clear when previewing an oEmbed from Add Media Panel
    • #30392 – Focus moves out of insert media overlay when tabbing beyond Insert into post button – Fixed
    • #30386 – Keyboard user has to tab through all uploade dimages to insert an image
    • #23562 – Using speech recognition software with the add media panel
    • #28864 – Cannot access edit menu options with keyboard inside Image Editor
    • #26550 – Some anchor links should be buttons in media microtemplates
    • #25103 – Submit buttons on form fields in the Add Media Panel

    Post Editing and Authoring

    There are a number of outstanding issues relating to authoring and editing posts, largely relating to some confusing tab order and needed improvements in flow both for mobile and users with disabilities. The current set up provides an extremely easy tab navigation from the title to the post content fields, but accessing anything in between via keyboard can be quite confusing. See also the flow comments from Mark Jaquith.


    • #29838 – Post editing area: keyboard accessibility, tab order, and focus
    • #23760 – Cannot use spacebar to trigger OK button or links in Publish widget
    • #30368 – Issue with category selection using voiceover
    • #27555 – Make tag post meta box more accessible
    • #30407 – Add keyboard shortcut for switching between Visual and Text editors
    • #30490 – TinyMCE: switch editor tabs focus style
    • #30619 – The wpView toolbar is not accessible by keyboard
    • #30345 – Quick edit: form submitted when activating cancel via keyboard – Fixed
    • #28431 – There’s no way to close the “keyboard shortcuts” modal with the keyboard – Fixed

    Use of .screen-reader-text in front-end

    This is a long-standing issue in handling some front-end accessibility issues. Numerous proposals have been floated, but there’s no strategic goal right now. Among the proposals are to add a theme support registry for the class .screen-reader-text, to set up core styles for the front-end that implement a .screen-reader-text class, or to simply add new information with that class and leave it to theme authors and site admins to handle the changes in front-end HTML output. This effects several other tickets. (I may not have caught all of them.)

    Part of the question here is for any future needs to add contextual references to core output: at what level is it necessary for us to avoid HTML changes on the front-end?

    • #29699 – add_theme_support( ‘screen-reader-text’ );
    • #18650 – Accessible dropdown widgets
    • #26553 – Comments popup link

    Visual focus indication in Admin Menu

    This ticket has gotten a lot of design attention but was not completed in time for 4.1. It needs further UI feedback.

    • #28599 – Better visual focus indication in Admin Menu

    Miscellaneous outstanding issues

    There are a large number of HTML inconsistencies, such as missing labels, links used as buttons. Not all of them have outstanding tickets, but I’m aiming to spend some time clearing out these minor issues so that we can better focus on more complex issues. Most of these are very small issues that with simple HTML/JS/PHP changes, but might require some CSS updates. And we all know how fun it is to spend time in the WP admin stylesheet.

    I know that there are some issues that don’t yet have tickets; I’ll be raising those, as well.

    • #28873 – Javascript code for adding bookmarklet Press This is hard to access with keyboard only
    • #30486 – Missing label associations throughout network admin
    • #29715 – Not-unique accesskey values may break quick edit and bulk edit form submission
    • #26562 – Remove title attributes class-wp-admin-bar.php
    • #26600 – Search installed themes input has no submit button
    • #29955 – Section 508 issues found on WP 4.0 admin page
    • #26504 – Semantic elements for non-link links
    • #30685 – Better Login Error and Message displaying
    • #21221 – Image title and alt attribute content should be texturized
    • #30914 – WP List Table: improve table footer tab sequence
    • #26601 – Inappropriate content in heading on Themes page
    • #29022 – Screen reader text and link title isn’t updated when plugin update count is updated
    • #26167 – Plugin activation links need to contain plugin name and the Plugin column should be marked as row header
    • #26550 – Some anchor links should be buttons in media microtemplates
    • #30706 – Add aria-describedby to autofocused fields
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