Category Archives: Core

David A. Kennedy 2:34 pm on September 14, 2015
Tags:   

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

Joseph Karr O'Connor 5:03 am on August 13, 2015
Tags: , ,   

Team Chat Summary August 10, 2015

New Structure Proposed

Rian Rietveld wrote a proposal on how to structure our work better and plan ahead longer and we discussed it. What follows is examples from the proposal.

Goals and Issues

This will be a separate page on make/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) and also a main menu item. It gives an overview of our goals for the accessibility of WordPress, the work we (want to) do, how this is organized, how we test, a roadmap for the next year and how we track the progress of issues we are working on. An example of the roadmap for release 4.4:

Release 4.4 (December 2015, Scott Taylor)
  • Finish still open issues focus from 4.3
  • Semantic heading structure Admin
  • The customizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings.
  • Handbook
  • Twenty Sixteen (?)

Central Ideas

Some central ideas also included in the proposal are keyboard focus, work on the handbook, color contrast, system to better follow tickets including splitting up tickets among team members on which to concentrate, and continue to develop code pattern library. Much more is included in the proposal and for now we will continue to work on the proposal to make it a more formal document to cover our activities over the next year.

We also talked about the fact that having a planning document to refer to does not obviate the need to address all new features since there is a tight turn around towards the end of a cycle because that’s when the features going into the release are announced. If we don’t follow all new features we might miss one or more that advance to release at the very end.

When we have it shaped up we will add the planning documentation to this blog in the form of pages and sub-pages to make it a community resource.

#accessibility-team-meetup, #team-reps, #weekly-meetings

Joe Dolson 10:06 pm on September 17, 2014
Tags: 4.1, ,   

WordPress Accessibility Ticket priorities for 4.1 early

WordPress 4.1 development is just started. 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, this means that we know almost nothing about what new features and 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. changes will be taking place, but it gives us a great opportunity to work on resolving older outstanding issues or addressing concerns arising out of version 4.0.

This is a grouping of the tickets currently in the Accessibility Focus report; no new tickets were opened for the purpose of this list.

One general recurring topic in these tickets is the handling of focus in modals. This is something that could stand some global work: all WordPress modals should be initiated and closed in a standardized way: focus should be assigned to the first focusable item in the modal when it’s opened, focus should be restricted to within the modal while it’s open, and the modal should be closable using ‘Esc’. A thorough review of all modals would be valuable.

Group 1:

These tickets have an impact on the front-end use of WordPress. They are very unlikely to be relevant to any new features in development for 4.1, but are longstanding issues and improvements. Because they alter front-end code, they may require more time in trunk to address impact on plugins or themes.

  1. #15926 Add alt attribute support for Custom HeaderHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. functionality
  2. #24148 Add aria-labelledby attributes to comment form (fixed)
  3. #21221 Image title and alt attribute content should be texturized.
  4. #27402 Add aria-describedby to image gallery output (fixed)
  5. JS #27645 MediaElement.js player & playlist not keyboard accessible (see Issue 1262 and Pull 1090 on MediaElement for reference)
  6. #16433 Extend function to optionally include commenter name in comment_reply_link
  7. #18650 Make archives and categories widgets dropdown ada compliant (depends on #29699)

#18650 is a particularly long-standing issue which has significant challenges due to the way the front-end 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. would need to change to make the feature accessible. Other features should all be able to be addressed without any major front-end impact.

Group 2:

These are areas that received a lot of attention in 4.0, but have outstanding issues. #26167 doesn’t directly relate to the plug-in work done in 4.0, but would be a good area to get resolved. It should be an easy fix.

  1. JS #28892 CustomizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings. – Widgets – Feedback for screen reader users when Moving widgets + other actions
  2. JS #28888 Customizer – Widgets – Screen Readers Don’t Announce WidgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user. Names
  3. #20880 Keyboard navigation in Appearance > Header is broken
  4. #26167 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 activation links need to contain plugin name and the “Plugin” column should be marked as row header
  5. JS #29371 Media Library: Focus keeps jumping to URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org field
  6. JS #29455 Plugin Info Modal Close Button Does Not Announce for Screen Readers
  7. JS #29326 Improve accessibility of edit-selection mode

Group 3:

General issues relating to the author experiences, that can impact a user’s ability to author content.

Add Media Experience:

  1. JS #25103 Submit buttons on form fields in the Add Media panel
  2. JS #23562 Using Speech Recognition Software with the Add Media Panel
  3. JS #28864 Cannot access edit menu options with keyboard inside Image Editor

TinyMCE/Editor:

  1. JS #29838 Post editing area: keyboard accessibility, tab order and focus
  2. JS #27642 Keyboard Accessibility for TinyMCE image panel
  3. #27553 Make WP editor toggle focusable
  4. #21414 Use the “Keyboard Shortcuts” checkbox in the user profile to turn on/off all custom shortcuts
  5. #29358 Remove the ‘accesskey` attributes from Quicktags buttons

Other:

  1. JS #27555 Make tag post metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. box more accessible
  2. #26600 Search installed themes input has no submit button
  3. #26550 Some anchor links should be buttons in media microtemplates

Group 4:

Administrator/Designer experience:

These issues will effect a smaller number of users on fewer occasions because they primarily effect issues related to site set up and configuration. #18801 could really stand some major work; the settings pages in WordPress have a large number of miscellaneous accessibility issues, but I think that the ticket is too all-encompassing as is; we need to open some individual tickets handling specific issues in the settings pages or in the APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways., so that the issue is more readily addressed.

  1. JS #27592 Screen Reader Users Do Not Know Widgets are Expandable
  2. #27593 Widgets: Toggle arrows on focus need an indicator beside color alone
  3. #18801 Accessibility Enhancements to Settings API

These are issues that make features more difficult to use, but don’t prevent the usage of the feature.

  1. #26758 Edit Tags form on submission does not stay at the same page and gets redirected
  2. #28873 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/. code for adding bookmarklet Press This is hard to access with keyboard only
  3. #25111 Keyboard focus does not stay within Full Screen Editor modal
  4. #26562 Remove title attributes: class-wp-admin-bar.php
  5. CSSCSS CSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site./HTML #26504 Semantic elements for non-link links
  6. JS #26601 Inappropriate content in heading on Themes page
  7. #26551 Remove title attributes: link-template.php
  8. #26560 Remove title attributes: rss.php

Group 5:

These are tickets we recommend for closure.

  1. #29475 Adding ARIA roles in wp_nav_menu
  2. #26553 Remove title attributes: comment-template.php

#4-1, #a11y, #tickets

David A. Kennedy 7:47 pm on August 27, 2014
Tags: 4.0   

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

Joe Dolson 8:01 pm on December 12, 2013  

Remove title attributes trac tickets

I’ve created all new tickets for each file referenced from the original remove title attributes trac ticket (https://core.trac.wordpress.org/ticket/24766). I originally split it up into 17 separate tickets, but closed 3 of them already, because they had already been committed into 3.8 or earlier.

I’ve added comments and/or patches, as relevant, on all of the remaining tickets – so please chime in with opinions as relevant! Many of these incorporate situations where a 2nd opinion would be valuable, because the title attribute incorporates relevant information and some alternative handling may be necessary.

Tickets:

https://core.trac.wordpress.org/ticket/26547
https://core.trac.wordpress.org/ticket/26549 – 2nd opinion
https://core.trac.wordpress.org/ticket/26550 – 2nd opinion
https://core.trac.wordpress.org/ticket/26551 – 2nd opinion
https://core.trac.wordpress.org/ticket/26552 – 2nd opinion
https://core.trac.wordpress.org/ticket/26553 – 2nd opinion
https://core.trac.wordpress.org/ticket/26554
https://core.trac.wordpress.org/ticket/26555 – 2nd opinion
https://core.trac.wordpress.org/ticket/26557
https://core.trac.wordpress.org/ticket/26558 – 2nd opinion
https://core.trac.wordpress.org/ticket/26559
https://core.trac.wordpress.org/ticket/26560 – 2nd opinion
https://core.trac.wordpress.org/ticket/26561 – 2nd opinion
https://core.trac.wordpress.org/ticket/26562 – 2nd opinion

Graham Armfield 11:30 am on November 28, 2013
Tags: , ,   

Analysis of what gets into the alt and title attributes when adding an image into a page/post

There was some debate in last night’s IRC chat about trac ticket 26270 raised by @yaelkmiller. Her original point was that when adding images to pages and posts, the Alt text box should have more prominence than the Title box – the alt attribute being an important 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) feature.

Personally, I think the idea is a good one, but discussion and comments by @helen also revealed some interesting behaviour when inserting images concerning what text ends up in the title attribute of the image, and what text ends up in the alt attribute.

I’ve done a series of tests using different use cases and they are presented in the tables below – including my expected results and the actual results.

Uploading images

Test No. Use Case Graham’s Expected Result Actual Result in Page
1 Upload image, add it to page with no change to Title box or Alt text box Title attribute set to image name minus suffix Title attribute absent, alt attribute set to image name minus suffix – ie what the Title box was set to
2 Upload image, add it to page but change Title box, not Alt text box Title attribute set to amended value Title attribute absent, alt attribute set to amended Title box value
3 Upload image, add it to page but change Alt text box, not Title box Title attribute set to image name minus suffix, alt attribute set to amended value Title attribute absent, alt attribute set to amended Alt text box value
4 Upload image, add it to page but change both Alt text box and Title box Both title and alt attributes set to amended values Title attribute absent, alt attribute set to amended Alt text box value

Using images from media library (previously uploaded) without amendment

Test No. Use Case Graham’s Expected Result Actual Result in Page
5 Add image from media library that has Title box set but not Alt text box Title attribute set but not alt Title attribute absent, alt attribute set to whatever Title box was before
6 Add image from media library that has Alt text box set but not Title box Alt attribute set but not title Alt attribute set but not title
7 Add image from media library that has both Title box and Alt text box set Both attrubutes set Title attribute absent, alt attribute set to whatever Alt text box was before
8 Add image from media library that has neither Title box nor Alt text box set Title attribute absent, alt attribute empty Title attribute absent, alt attribute empty

Using images from media library (previously uploaded) but making amendments

Test No. Use Case Graham’s Expected Result Actual Result in Page
9 Add image from media library, that has just Title box set, update Title box Title attribute set but not alt Title attribute absent, alt attribute set to whatever Title box was amended to
10 Add image from media library, that has just Alt text box set, update Alt text box Alt attribute set but not title Title attribute absent, alt attribute set to whatever Alt text box was amended to
11 Add image from media library, that has neither Title box set nor Alt text box set, update Title box Title attribute set but not alt Title attribute absent, alt attribute set to whatever Title box was amended to
12 Add image from media library, that has neither Title box set nor Alt text box set, update Alt text box Alt attribute set, no title attribute Title attribute absent, alt attribute set to whatever Alt text box was amended to
13 Add image from media library, that has both Title box and Alt text box set, update Alt text box Both attributes set Title attribute absent, alt attribute set to whatever Alt text box was amended to
14 Add image from media library, that has both Title box and Alt text box set, update Title box Both attributes set Title attribute absent, alt attribute set to whatever Alt text box was originally set to

Looking at the results

Using the Add Media Panel to insert an imageThe first revealing thing about these tests is that my own view of how I thought WordPress worked is at odds with the actual results in most cases.

The second thing that’s become obvious is that it’s actually impossible to set the title attribute for an image whilst using the Add Media panel. The title attribute never appears in any of the results.

Actually the only way to set a title attribute image within pages and posts is to use the older image edit dialogue box once the image is placed within the page (or to manually update the 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. obviously).

I think the confusion comes from the labeling of the Title input field in the Add Media Panel. Helen refers to this in her comments on the tracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. ticket I believe. Maybe to avoid confusion this box should be given another label – ‘Image name’ maybe. I confess that I hadn’t noticed this change in WordPress behaviour – it did used to be possible to directly influence the title attribute of an image when uploading and adding it to a page/post.

I’m sure that I’m not the only one who didn’t appreciate this situation. There is a 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 called Shutter Reloaded that I’ve seen on a couple of sites, which uses the title attribute from the image to provide a caption beneath the image when the full size is shown. Obviously this plugin is broken if site admins don’t realise the title attributes aren’t being written into the <img> tags – and the plugin author perhaps doesn’t realise either. I can’t comment on other lightbox plugins.

What do you think? Is this what you expected? Is this the right way to go?

#images, #media-manager, #testing

esmi 9:00 am on August 9, 2013
Tags: , ,   

Title Attributes Galore

The patches for Trac ticket 24766 are slated for addition to WordPress 3.7. This is great news for 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 users who have been forced to wade through a sea of unnecessary title attribute verbiage. But we need to ensue that the patches cover all unnecessary title attributes and that those deliberately excluded from the patches do not present any 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) issues.

Currently, the excluded methods, functions and scripts are:

  • the_author_posts_link()
  • rss.php
  • wp_fullscreen_html()
  • get_adjacent_post_rel_link()
  • _walk_bookmarks()
  • get_image_tag()
  • the_shortlink()

Continue reading →

#tabbing, #trac-2, #ui

Graham Armfield 4:56 pm on July 8, 2013
Tags:   

Accessibility Objectives for WordPress – Initial Thoughts

Some of us have been talking recently about pulling together some 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) objectives for WordPress. These are things that we feel could, or should, be happening to ensure that the profile of accessibility is enhanced with the WordPress community.

Ultimately, in order to support Matt Mullenweg’s view on the democratisation of the web by web-related software we want as many WordPress websites as possible to be accessible to as many people as possible. We also need to ensure that the WordPress admin screens are not excluding certain user groups from key parts of functionality.

With that in mind, here is our initial list of objectives. Please feel free to comment on these, and to suggest others that you think are also important.

Continue reading →

#accessibility

esmi 8:01 pm on June 25, 2013
Tags: , ,   

Next IRC Meetup

Just a quick reminder that the next IRC meetupMeetup All local/regional gatherings that are officially a part of the WordPress world but are not WordCamps are organized through https://www.meetup.com/. A meetup is typically a chance for local WordPress users to get together and share new ideas and seek help from one another. Searching for ‘WordPress’ on meetup.com will help you find options in your area. will be on Wednesday, 26 June at 19:00 UTC in #wordpress-iu.

Everyone welcome!

If you have never attended an WordPress IRC meetup before, you can find all of the details you will need to join in the Codex’s IRC page.

One topic for discussion is likely to be the development of a proposed 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) statement for WordPress. To whet your appetite and give you an idea of what we could aim for longer term, have a look at Drupal’s accessibility statement.

#core-2, #development, #meetup

Graham Armfield 10:31 am on April 4, 2013
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 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), 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?

#accessibility, #add-media, #irc, #keyboard, #media-manager, #screen-reader, #testing