WordPress.org

Ready to get started?Download WordPress

Make WordPress Accessible

Recent Updates Page 2 Toggle Comment Threads | Keyboard Shortcuts

  • 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
    Tags: Theme Pattern Library   

    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.

    Goals

    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

    Implementation

    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.

    Questions

    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.

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

    Tickets:

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

    Tickets:

    • #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
     
  • Joe Dolson 6:07 pm on December 15, 2014 Permalink
    Tags:   

    Taking Steps for More Accessible Themes 

    We’ve been working with the Theme Review team to coordinate sharing more information about making themes accessible, with an eye towards the goals in our Accessible Themes Roadmap. The first step in that roadmap has been published today, Three Easy tips for Accessible Theming, published at the Make/Themes blog.

    Read it, share it, and most of all, build accessible themes for WordPress!

     
  • Rian Rietveld 6:09 pm on December 8, 2014 Permalink  

    The weekly test session on Monday will be postponed until Monday January 5 2015.

     
  • Joe Dolson 5:41 pm on December 4, 2014 Permalink
    Tags:   

    Theme Accessibility Meeting Notes 

    We had a great meeting to discuss the future of theme accessibility. You can review the complete transcript of the chat in Slack.

    We discussed many of the aspects of what it will take to make accessibility a requirement for themes – it’s a long process, but we agreed that this is possible. We started by discussing where the most appropriate place is to publish our kick off article, which is going to give three examples of areas where theme authors can improve the accessibility of their themes immediately. It will be published either on Make/Themes or here on Make/Accessibility, followed by an extensive effort to share in the community.

    Next we discussed the fledgling repository for WordPress-specific code examples for accessibility. The repository already exists at GitHub, so it’s just a matter of writing code and organizing it. David Kennedy will take the lead on developing that resource.

    Moving on, we discussed how to organize theme accessibility information and advice into the Theme handbook structure. We concluded that a conversation about how that fits in is needed, and I’ll have that with Tammie Lister before we decide exactly what those documents will be, as well as moving the existing Accessibility guidelines around in the theme reviewer’s handbook.

    Morten Rand-Hendriksen reviewed the original plan sketched out at the community summit to give people who weren’t there a basic understanding of the conversation.

    This brought up a conversation about future handling of the ‘accessibility-ready’ tag and how we should share information in the WordPress theme repository about whether a theme has been reviewed for accessibility. Right now, it’s fairly moot given the small number of themes that have been reviewed, but by the time accessibility becomes a requirement, it will be important to start labeling, to take the onus off end-users to discover whether their theme will allow them to meet their country’s legal requirements for accessibility.

    Both these issues will need to be proposed to the theme review team, so we’ll be working on writing a precise proposal that can be taken to that team and be voted on. The important thing with the proposal is clarity.

    Finally, we discussed theme reviewer training. I’ll set up a date with Tammie to work through the process with her, but will ultimately need to do something that’s less one-on-one, either through a detailed written document or a video training resource. This training process would be greatly helped by having the code repository fleshed out, so that those code examples are available to reviewers and theme developers.

     
    • tady 1:37 pm on December 11, 2014 Permalink | Log in to Reply

      Hi folks, would it be possible to get an invite to this Slack group? I appear to have missed out on the notification regarding the move from IRC to Slack.

      Cheers,

      T

    • Ipstenu (Mika Epstein) 2:55 pm on December 11, 2014 Permalink | Log in to Reply

      tady, go here: https://make.wordpress.org/chat/

      You can sign up that way :)

    • Matt Mullenweg 3:59 pm on December 18, 2014 Permalink | Log in to Reply

      I don’t think there’s any real advantage to making it a requirement, an opt-in tag gives both discoverability and distribution.

      • Deborah 2:01 pm on December 20, 2014 Permalink | Log in to Reply

        Perhaps I’m missing something, but how is translation a requirement, but accessibility isn’t?

        • Joe Dolson 4:15 pm on December 20, 2014 Permalink | Log in to Reply

          “translation” is not a requirement; “translation-ready” is a requirement — those are two very different things. Translation-ready is actually a fairly trivial task to undertake. That said, so is accessibility-ready, in 95% of cases. I’m fully in favor of making some aspects of what constitutes an accessibility-ready theme required, but not necessarily all aspects; things like color contrast, with so many themes providing color changing tools and authors inevitably targeting color as one of the first things they will change, is practically irrelevant for themes.

          However, in the end, this will be a community decision.

  • Joe Dolson 4:33 pm on November 29, 2014 Permalink  

    Planning Theme Accessibility for 2015 

    At WordCamp San Francisco, several members of the community including members of the WordPress Accessibility team met to discuss the future of accessibility for plugins and themes in WordPress.org repositories. While the accessibility-ready theme tag has been successful, it only scratches the surface of the long-term goals for accessibility in both environments.

    Discussion of issues within the plug-in repository were brief; essentially, the plug-in repository is seen as a jungle, and we’re not really prepared to tackle that beast. However, the accessibility of themes is something that we can address, and that’s our goal in the coming year.

    At the community summit, we worked out a roadmap for meeting these goals, with a target of making some level of accessibility a requirement in order to submit a theme into the theme repository.

    The primary tasks along the way include authoring code examples to be housed in a community GitHub repository, authoring tutorial documents and detailed guides to help authors meet the requirements, and providing training to theme reviewers to help handle these requirements.

    But there are a lot of details left to be worked out, and people to get involved in the process.

    We’ll be having a meeting in the Accessibility channel for WordPress at 16:00 UTC on Thursday, December 4th to discuss goals and assign tasks. If you’re interested, please attend!

    Basic Agenda

    1. Updates on progress from those already working on the project.
    2. Talk about timeline for goals
    3. Discuss written documents needing to be prepared
      1. Where they should be published
      2. Who will write them
      3. Editorial process
    4. Discuss theme author and reviewer training
     
  • Graham Armfield 4:32 pm on November 29, 2014 Permalink  

    WordPress Accessible Themes Roadmap 

    Initial Proposed Timeline

    What When
    Initial content (3 initial steps) December 12 2014 Published Dec. 15, 2014
    All resource copy written Late January 2015
    Code library finished Note April 2015
    All accessibility info published in various locations (See below) April 2015
    All new themes to automatically be tested for accessibility November 2015

    Brainstorm of Content Types

    We felt that the following pieces of information should be provided for theme dev (and others) to help them understand the reasons why accessibility is so important, and how to actually go about bringing accessibility techniques into themes.

    • The 3 steps – the top 3 things to do to improve accessibility within a website. These are:
      • Keyboard navigation
      • Controls that aren’t controls
      • Unidentified images
    • A resources page – “A  way in”
    • The WordPress Accessibility Guidelines – what WordPress defines as being accessible
    • A world map of accessibility legislation
    • Landing pages
      • on Make WordPress Accessibility (make.wordpress.org/accessibility)
      • on WordPress main site (wordpress.org/accessibility)
    • Why accessibility is important – prose + video
    • How to do accessibility – prose + video
    • Pattern library
      • best practices prose – explaining what and why
      • code snippets – examples that you can use
    • Examples of attractive accessible themes
    • How to make your themes accessible
    • How to test that your theme is accessible
    • A list of gotchas for plugins (perhaps an impostor from another page)

    Other potential accessibility reference sections – but not specifically theme related:

    • Guide for writing content in an accessible way

    Stimulating Phrases

    During our sessions we came up with a series of phrases that were worth capturing as they can stimulate work in different directions and underpin our ethos:

    • Take the onus off the user – A user of a WordPress theme should not have to worry about the accessibility of the theme.
    • Accessibility is coming, it is not going away.
    • Checking all themes for accessibility
    • WordPress will be accessible by default
    • An opt-out for theme authors, but themes flagged as not tested
    • This theme has not been checked for accessibility
    • This theme was approved before WP a11y guidelines were published
    • What’s our theme tagging strategy
    • Accessible icons for themes
    • Automated testing vs manual testing
    • The bonus of SEO from doing accessibility
    • Check the accessibility of the underscores theme and Bones
    • Dispel the myths about accessibility
    • An aggressive timeline
    • An outreach programme

    Places that need links to accessibility resources

    • Make WordPress Accessible
    • WordPress.org Accessibility
    • Theme Handbook
    • Developer Handbook
    • Theme upload page
    • Training team page(s)

    That’s “finished” for a given value of finished. Return

     
  • Joe Dolson 6:49 pm on November 17, 2014 Permalink  

    Accessibility Ticket Priorities for 4.1 beta 

    Now that WordPress 4.1 is into beta, it’s time to tighten the focus on accessibility tickets to the top priorities to get into the 4.1 release. As always, early in the cycle is a great time for general accessibility work, and late is time for polishing new interfaces and tackling small details that can make the whole thing better with minimal impact.

    Update, 11/22/2014: 6 issues fixed.
    Update, 11/25/2014: 1 issue fixed, one punted for 4.2-early
    Update, 12/4/2014: 1 issue fixed
    Update, 12/8/2014: 1 issue fixed

    New features

    New interfaces should be checked immediately, to verify that there aren’t any major issues. In WordPress 4.1, the significant UI changes are Session Manager (found on the user profile page when logged into multiple instances), Site Language (Settings > General), Focus (editor distraction-free-writing). Other changes are more iterative, including changes to focus states and color contrast – on the whole, there are only minor updates to the UI in 4.1.

    Twenty Fifteen is also a major addition in 4.1, and has received a lot of feedback already.

    Relevant tickets:

    • #30364 – Destroy sessions feedback and valid HTML Fixed.
    • #28599 – Better Visual Focus Indication in Admin Menu

    There are currently no other outstanding tickets pertaining to these new features or Twenty Fifteen. Woot!

    Iterations to recent features

    The Add Media Panel is still a source of enormous complexity with outstanding issues, as is the Customizer. These tickets are JS heavy, for the most part, and could use somebody with a good JS sense to weigh in.

    Add Media Panel

    • #29326 – Improve accessibility of edit mode (slated for 4.1 already) Fixed
    • #29371 – Focus keeps jumping to URL field – Closed, replaced with #30512
    • #29455 – Plugin Info modal close button does not announce (just needs commit) Fixed
    • #28864 – Cannot access edit menu options with keyboard inside Image Editor
    • #25103 – Submit buttons on form fields in the Add Media Panel
    • #30348 – Arrow key navigation in Media Grid skips ids Fixed
    • #30390 issue with keyboard/VO accessibility for uploading new images in Safari using the Add Media Panel. Fixed

    Customizer

    • #22237 – Add keyboard shortcuts for collapse/expand, panel-back, and close to the Customizer
    • #28892 – Customizer – Widgets – Feedback for screen reader users when moving widgets/other actions Fixed

    Miscellaneous issues

    • #26167 – Plugin activation links need to contain plugin name and the “Plugin” column should be marked as row header
    • #26758 – Edit tags form on submission does not stay at the same page and gets redirected
    • #28873 – JS code for adding bookmarklet Press This hard to access from keyboard
    • #29022 – Screen reader text (and link title) isn’t updated when plugin update count is updated
    • #29958 – Collapse admin menu keyboard accessibility
    • #30010 – Hide admin menu separators from screen readers Fixed
    • #29715 – Remove accesskeys from quick edit and bulk edit

    Iterations to front-end output and related functions

    • #21221 – Image title and alt attribute content should be texturized.
    • #30180 – wp_get_attachment_image_src does not return alt or meta.
    • #29808 – Post/paging navigation template tags Fixed
    • #29974 – Focus handle at wrong place when you click reply

    I’m specifically targeting easy targets to whittle down the ticket list, to clear space in the report for new issues and some of the long-outstanding major concerns for 4.2. In 4.2, it would be nice to hit some broad issues like the settings pages in general and the usage of anchor vs. buttons across the UI.

    This isn’t everything, but it hits a lot of issues that have received work and just need to be finished off.

     
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