Testing Twenty Sixteen

By now, I’m sure you’ve noticed Twenty Sixteen has been released on Github and the theme repository to spur development and testing. If you haven’t tested the theme for accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility), now’s the time! I mentioned it in a recent chat, and a members from the community have already tested it, but the more the merrier!

What do I test?

Test the theme according to the accessibility-ready requirements. Since this is a default theme, you should test for the recommendations too. Also, it’s a good idea to look at the applicable WCAG 2.0 requirements (Link is not the official WCAGWCAG WCAG is an acronym for Web Content Accessibility Guidelines. These guidelines are helping make sure the internet is accessible to all people no matter how they would need to access the internet (screen-reader, keyboard only, etc) https://www.w3.org/TR/WCAG21/. requirements, but a more readable version), and test the theme according to those, within reason. This way, the theme can be its best accessibility-wise.

How do I test?

The accessibility-ready requirements give some information on how to test. We also have a list of tools that will help when testing.

How do I report bugs, issues or make a enhancement request?

  • Create an issue on Github.
  • If you can’t create an issue on GithubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/, comment on this post.
  • If you can’t do that, drop us a note on our contact form, making sure you mention Twenty Sixteen.

What information do you need to know when creating an issue?

Here’s a good format to follow when creating a bug report:

Title: Accessibility: ISSUE SUMMARY HERE

What I Did:

What I Expected:

What Actually Happened:

I’m not a developer, how can I help?

No problem! You don’t have to be a developer to help out. Test the theme on your favorite operating system with assistive technologyAssistive technology Assistive technology is an umbrella term that includes assistive, adaptive, and rehabilitative devices for people with disabilities and also includes the process used in selecting, locating, and using them. Assistive technology promotes greater independence by enabling people to perform tasks that they were formerly unable to accomplish, or had great difficulty accomplishing, by providing enhancements to, or changing methods of interacting with, the technology needed to accomplish such tasks. https://en.wikipedia.org/wiki/Assistive_technology. This way, we get a better idea of how the theme works with different configurations. Try to break the theme! Note anything that is confusing, and makes the theme harder to use on the front end.

#twenty-sixteen

Accessible Theme Pattern Library Update for March

Another month has passed, and work on the AccessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) Theme Pattern has chugged along.

What’s Happened? We have code committed for four additional pattens, beside the read more links one that got us going. They are:

  • A skip link.
  • A skip link for Genesis themes.
  • Dropdown menus with jQuery and without jQuery.
  • Comment form, enhanced with JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. and ARIA.
  • Two more patterns in progress: responsive menu and mobile menu modal.

We’ve moved from separate repositories on GithubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ to just one. All the patterns live in sub-directories within that repository. It’s called a11ythemepatterns. Within that, we also have a basic readme file and a contributions file, explaining how to contribute.

You can see the in-progress patterns in the issues on Github.

Note: The patterns are also still available via their own separate repositories, which you can see on our Github account. Don’t use/fork those, as they’ll be removed soon. Use the a11ythemepatterns repository.

If you have questions, don’t hesitate to ask in the comments.

#theme-pattern-library

Accessibility Team Update: Week of March 2, 2015

This week, the team covered a range of topics, mostly giving each other updates on ongoing projects. Chat archive in Slack.

We talked about the accessible theme pattern library, which is ongoing. I’m leading this effort, and hope to hit 10 patterns before starting on a handbook for the accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) team.

@rianrietveld gave an update on our weekly testing sessions, which happen every Monday. She says:

Last week we tested:

  • #31143 – Login error handling accessibility improvements
  • #31326 – Edit comment screen: misplaced-missing labels

This week we retest the update/install plugins after the introduction of wp.a11y.speak().

Full report on the testing.

@afercia updated us on wp.a11y.speak, which is a tool for developers to dispatch feedback messages text strings to an `aria-live` region within the WordPress Admin area. This makes it easier for users with assistive technologyAssistive technology Assistive technology is an umbrella term that includes assistive, adaptive, and rehabilitative devices for people with disabilities and also includes the process used in selecting, locating, and using them. Assistive technology promotes greater independence by enabling people to perform tasks that they were formerly unable to accomplish, or had great difficulty accomplishing, by providing enhancements to, or changing methods of interacting with, the technology needed to accomplish such tasks. https://en.wikipedia.org/wiki/Assistive_technology to know what’s happening on the screen.

We also talked about the upcoming enhancement deadline, and what we might need to retest and coordinate with the CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. team. @afercia attended the Core meeting that day to help coordinate the efforts.

We also agreed as a team to rotate a team representative to attend the Core development meetings. @afercia has handled that recently, and we’ll get a schedule up on this site soon. To start, @rianrietveld will take April and I’ll take May.

See you next week everyone!

#weekly-meetings

Accessible Theme Pattern Library Update for February

About a month ago, I announced that work on an accessible theme pattern library had started. Progress has moved forward steadily since then.

Six people have volunteered to create patterns and code has been written! 🙂

The volunteers are myself, @cheffheid, @joedolson, @chrisdc1, @arush and @rianrietveld. You can see the list of patterns on this Google Doc. I’ve also created the appropriate repositories on Github for the patterns that people volunteered to lead and/or create. I’ve kicked things off with code for Read More links, modeled after Twenty Fifteen.

What’s Next?

  • We’ll start writing more code. If you want to contribute, fork one of the existing repositories and make a pull request. If you code exist yet, get in touch with the lead for that pattern. You can find that in the Google Doc spreadsheet. For contributions, we’ll use the fork and pull method.
  • If you have an idea for a new pattern, comment on this page and leave your idea.
  • If you want to lead the creation of a pattern, ping me in Slack (davidakennedy) and let me know. I’ll add your name to the spreadsheet in Google Docs.

If you have questions, just comment on this post. You can follow along with our progress via the Theme Pattern Library tag.

#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 accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/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 CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. 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 HTMLHTML HTML is an acronym for Hyper Text Markup Language. It is a markup language that is used in the development of web pages and websites., CSSCSS CSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site., JS and PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. http://php.net/manual/en/intro-whatis.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 GithubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ 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.

#theme-pattern-library

Time to Test Twenty Fifteen!

Today, Twenty Fifteen landed in /trunk.

@iamtakashi and others have worked really hard to make this first pass accessibility-ready from the start. 🙂

I’ve done an initial accessibility-ready review and advised on a few bug fixes. But we still should bang and bend this lovely theme from an accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) perspective.

Note: This theme has different color schemes, so keep in mind only the default one needs to meet the accessibility checks.

We’d love to find a more elegant solution for the focus styles on the main navigation links.

If you’re not comfortable filing a ticket, just comment here and we’ll consolidate them into feedback on future tickets.

Please post all feedback here. If you are using assistive technologyAssistive technology Assistive technology is an umbrella term that includes assistive, adaptive, and rehabilitative devices for people with disabilities and also includes the process used in selecting, locating, and using them. Assistive technology promotes greater independence by enabling people to perform tasks that they were formerly unable to accomplish, or had great difficulty accomplishing, by providing enhancements to, or changing methods of interacting with, the technology needed to accomplish such tasks. https://en.wikipedia.org/wiki/Assistive_technology to test Twenty Fifteen, please indicate exactly what software you are using and web browser — including the version number, if possible.

To test Twenty Fifteen:

  1. Install WordPress locally.
  2. Download and install the Beta Tester plugin.
  3. Configure the Beta Tester plugin and update WordPress.
  4. Activate Twenty Fifteen and test to these standards.

October 15, 2014: Updated post with instructions on how to get Twenty Fifteen. Updated with additional feedback instructions.

#a11y-audit

Accessibility Team Update: October 8, 2014

Here’s our team update for the week:

  • We’re continuing our weekly testing meeting. Be sure you note the time in the sidebarSidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme., if you’re interested in participated.
  • We now have the Handbook pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party activated on our site and work has begun to create an AccessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) Handbook. Contact @davidakennedy if you’d like to help.
  • @trishasalas is working on tutorials for the accessibility-ready theme tag.
  • We discussed #29838 and how it might fit into some other work going on in CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress..

 

WordPress 4.0 Release Candidate Testing

The first release candidate for WordPress 4.0 is out. If you’re interested in testing for accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility), here’s what to focus on:

New features in 4.0

  1. Oembed
  2. Insert from URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org
  3. PluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party installation
  4. Editor scrolling
  5. Media Library Grid
  6. Customize Panels

Regressions from 3.9

We don’t have a definitive list for this, but keep an eye out for anything that’s not working that you know worked in the last version.

If you run into bugs, follow the instructions from the WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ announcement post:

Think you’ve found a bug? Please post to the Alpha/Beta area in the support forums. If any known issues come up, you’ll be able to find them here.

To test WordPress 4.0 RC1, try the WordPress Beta Tester plugin (you’ll want “bleeding edge nightlies”). Or you can download the release candidate here (zip). If you’d like to learn more about what’s new in WordPress 4.0, visit the awesome About screen in your dashboard ( → About in the toolbar).

Things to Watch

We want to keep things simple at this point. Look for any big blockers, like:

  • keyboard traps
  • confusing or non-existent tab order
  • content that can’t be accessed via keyboard
  • content that can’t be accessed via screen reader

#4-0

WordPress needs automated accessibility testing

The Make WordPress AccessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) Team needs help wrapping its arms around WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. as new features get created while helping refine the existing codebase to make it more accessible to people with disabilities. Our small team can’t be everywhere and test everything, but we’re working to gather an accurate picture of what needs our help the most.

Once we have a better idea of what needs our attention the most, how do we maintain a good grasp of it? Automated accessibility testing can help in a big way here, and I’d like to start working to incorporate it into Core. I brought this up in our last Accessibility Team chat.

What’s automated accessibility testing? Similar to unit testing, this would allow developers to run a set of tests during their local development workflow of patches for WordPress via a command line tool. These tests would output results that would alert developers to potential errors and help them fix things like missing alt attributes or unassociated form fields and labels. Automated accessibility testing isn’t perfect and it won’t help us overcome all of our challenges, but it can help us find simple, easy-to-fix errors, alert us to large trouble spots within the codebase that need more manual testing and allow us cover a bit more ground. It’s a nice compliment to the manual testing and education we’ve done so far.

What do we need to consider when selecting a tool?

WordPress Accessibility Team member Karl Groves has a nice blog post about this. He says you should consider three things:

  1. Flexibility and Freedom. These tools exist for one reason only: to work for you. Every single second you spend learning the UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing., figuring out how to use it, or sifting through results is a second of development time that could go into actually improving the system. The tool must be flexible enough to offer the freedom to use it in any environment by any team of any size in any location.
  2. Accurate. Developers of accessibility tools want to find every single issue they possibly can. This unfortunately often includes things that are, in context, irrelevant or of low impact. They also may require an additional amount of human effort to verify. This is a disservice. Tool vendors need to understand that their clients may not have the time, budget, or knowledge to sift through false positives. The user should be able to immediately eliminate or ignore anything that isn’t an undeniable issue.
  3. Understandable The user of the tool needs to know exactly what the problem is, how much impact the problem has, where it is, and how to fix it. Overly general, overly concise, or esoteric result descriptions are unhelpful. If a tool can find a problem, then it can make intelligently informed suggestions for remediation

I think these are good goals to try to hit. Ideally, we want something that will have little to no impact on a developer’s workflow, allow us to select different test criteria and deliver accurate results we can act on.

As research, I’ve spoken to Jesse Beach. She’s a Senior Front End Engineer at Acquia Inc., a Drupal contributor, a contributor to QuailJS (a tool Drupal uses for automated accessibility testing) and a member of the Drupal Accessibility group. She’ll help us look at QuailJS as a possible automated accessibility testing approach. And hopefully, we can share accessibility knowledge between these two awesome open sourceOpen Source Open Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL. projects! We talked about what we (WordPress Accessibility Team) want to accomplish with automated testing, how a tool might fit into a WordPress developer’s workflow, the future of QuailJS and a bit about accessibility in our different open source projects.

One other possibility on the short list of tools besides QuailJS includes Pa11y. We will likely look at others as well.

Next steps

  • Firm up a list of requirements for a tool
  • Experiment with some tools
  • Meet with Core team members to discuss
  • Develop test criteria

Your ideas and feedback are welcome!

#testing