Author Archives: Graham Armfield

Graham Armfield 12:37 pm on March 28, 2013
Tags: , , , , , , , ,   

Add Media Panel and WordPress 3.6 – A Simple Solution?

The betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. version of WordPress 3.6 is very close now and the chances of significant extra functionality being included must be slim. But, the Add Media Panel introduced in 3.5 is still inaccessible and the tracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. tickets raised on this are still untouched.

This is a real problem as the Add Media Panel is such a key piece of functionality.

However, from our IRC chat yesterday the germs of a simple solution may have emerged – a solution that could maybe make the functionality accessible to keyboard and screen reader users. We just need someone to give it a try.

Continue reading →

#accessibility, #add-media, #images, #irc, #keyboard, #markup, #media-manager, #screen-reader, #ui

Graham Armfield 10:52 am on March 18, 2013
Tags: , dialogs, popups,   

Accessible Dialogs and Popups

It seems there are an increasing number of areas where dialogs or popup panels are used to alert the user about occurrences and perhaps demand some action from them. Examples include the Autosave and Post Locking dialogs #23697 and Login Expiration #23295 – as pointed out by Joe Dolson.

Within #23697 @azaozz responded to some comments of mine re 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) by asking “Is there anything else we should be doing to make these dialogs better?”

My response to him was:

  1. When the dialog opens, keyboard focus must be transferred into a meaningful object within the dialog – suggest a heading that explains purpose of dialog. This item can be given tabindex=0 to allow it to receive focus both by scripting and tabbing.
  2. The purpose of the dialog should always be visible.
  3. Whilst the dialog is open, functionality will be needed to tidily cope with users tabbing beyond the controls/buttons in the dialog, or reverse tabbing before the entry point. Tabbing can either cycle within dialog if it’s important that user responds, or that tabbing outside confines of dialog closes the dialog.
  4. Whenever dialog is closed, keyboard focus should be returned to somewhere sensible – maybe the link/button that opened dialog in the first place, or to top of a new page if one is opened.

Does that sum it up, or is there more that could be added to that list?

#core-2, #dialogs, #popups, #ui

Graham Armfield 10:01 am on February 25, 2013
Tags: , , , ,   

Add Media Panel – Accessibility Issues

I’ve raised this post as I feel that the issue of 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) needs some debate amongst the accessibility community.

Last week I raised three WP tracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. tickets covering my take on the problems from the keyboard access, screen reader and VR aspects. They are: #23560 and #23561.

The main problem as I see it is that it is not possible to select/deselect any of the media without using a mouse.

The functionality primarily acts like a group of checkboxes – selecting one or multiple elements, with feedback that they have been selected. However, that is not how the functionality has actually been implemented – it’s a series of divs contained within an unordered list. There appears to be nothing to receive focus. There are links for each file, but the links appear empty although they are used to show the selected icon. These links are also initially invisible using CSSCSS CSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site. techniques that hide them from screen readers – hence the no tabbing into the images issue.

Is the use of ARIA going to really be able to help here?

When mouse users select an image they can update the attribute values for that image using the panel to the right – which updates its content automatically. Allowing keyboard users to quickly reach the attributes boxes would obviously be desirable – the alternative being tabbing through all the previously uploaded files.

The media selector panel has been implemented with infinite scrolling, so on mature and/or larger sites with many images/files (I have one) the list of images gets bigger and bigger. From an accessibility perspective I’d favour paging over infinite scrolling, but what’s your take on that?

Is this another area where bending the new functionality to include accessibility might be too much? Is this another place where an accessibility mode is going to be required?

What do you think?

#accessibility, #add-media, #images, #keyboard, #screen-reader

Graham Armfield 5:47 pm on February 15, 2013  

Creating Custom Menus

There is a lot of discussion and design going on at present concerning the changes that are being made to the Custom Menu Builder for WordPress 3.6. These discussions can be followed via trac ticket #23119.

But as part of that work the Custom Menu Builder needs to become easily accessible to those who can’t use a mouse, or who are using screen readers or speech recognition software.

During our IRC sessions this week and last we touched on potential solutions. So far the solutions have boiled down to:

  1. Use a separate accessible version in a similar way to how the accessible widgets functionality works.
  2. Ensure that the rebuilt functionality, which will almost certainly feature drag and drop contains and generates enough information to allow easy manipulation by those 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.
  3. Ensure that the markup of the solution externalises enough information about hierarchy and makes influencing it easy.

But we need some more input on how this functionality could be deployedDeploy Launching code from a local development environment to the production web server, so that it's available to visitors. accessibly.

Although the widgets method is usable, could it be better? If so, how.

Could a drag and drop solution with ARIA help really work for blind users?

Please feel free to comment with any ideas you may have.

Graham Armfield 5:08 pm on February 13, 2013
Tags: , , ,   

WordPress Accessibility Trac Tickets Update – 13 Feb 2013

This is a useful link that returns all the accessibility-related trac tickets.

Existing TracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. Tickets (Bugs) that aren’t Fixed.

12825 – Text resizing in Firefox – Raised 3 years ago(!) this one talks about the fact that WP admin screens don’t always look very clever when text is resized by user. Whilst most areas are OK, the buttons and toolbar at the top of the page are fixed-height and so text-spillage occurs. I don’t think everyone realises that zooming and resizing text are not the same thing and suit different people.

20294 – User password field missing label – Looks like some work was done for 3.5 but it appears it was never implemented.

21289 – Custom Menu builder – Raised last year but turned out to be duplicate of 14045 and linked to 22485. Ticket 23119 (see also below) is covering the rework of Custom Menus and design is still being debated hotly. Need to keep eye on this one as Custom Menu Builder has never been accessible since first introduced.

21334 – 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) of Quick Edit Panel – Raised last summer, and is getting some attention now. Have suggested (amongst other things) that quick edit panel might be always visible as a result of switch in Screen Options, but kind of nervous about that. Could do with some further accessibility input (ie not just mine). The issue about whether certain links should be permanently visible coming in here as well – cf Skip links at top of page.

22104 – High contrast admin colour scheme – Raised in the autumn, and some debate ensued. However nothing really happened about this. Do we want to get behind this? Is there one high-vis theme that would work for all?

22606 – Keyboard issues selecting a background image in Theme 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. – Seems there is a fix for this, but need to test.

22682 – More keyboard issues with Theme Customizer after page refresh – Some action but has been downgraded in importance just before Christmas.

22933 and 23195 – Keyboard tab order in edit screens – Fix is now available that makes tabbing more consistent allegedly. But I haven’t been able to test this.

Trac tickets covering 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. work

23119 – UXUX UX is an acronym for User Experience - the way the user uses the UI. Think ‘what they are doing’ and less about how they do it. improvements to nav-menus.php – A LONG ticket with much debate. Difficult to work out exactly what is being proposed for accessibility here. One ticket proposed that accessibility option like widgets should be included – and apparently the stubs for that code are actually in the menu builder and may be used if js not available. Cyndy pointed out within ticket that drag and drop, and even using arrow keys to move items is not really any good for blind people. But would that be an option if there was sufficient announcing (using ARIA live regions?) to allow context to be voiced? And is it OK to just use the arrow keys for this – when users might expect something different to happen? And what about users on tablets using AT like VoiceOver?

New tickets required?

Add Media Functionality – don’t believe this is keyboard accessible (inc screen readers), nor easily accessible by speech recognition software either. But haven’t had chance to test yet.

#core-2, #development, #media-manager, #menus

Graham Armfield 12:28 pm on February 6, 2013
Tags: , post formats,   

Are Trac Tickets Still the Best Way to get Accessibility Improvements in WordPress?

Last year, as a result of a number of tracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. tickets raised by myself and others, a number of 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) improvements were made to the WP admin screens in 3.5. This was a good thing in that it showed that some WP developers were happy to address the challenges with existing functionality. And for existing accessibility issues I suppose this is still the right vehicle.

However, I’m troubled with this approach when I think about new functionality that is being developed within every release of WordPress. So far in 3.6 I’m seeing that there are going to be significant changes to the UIs for Custom Menus, Post Formats, and Post RevisionsRevisions The WordPress revisions system stores a record of each saved draft or published update. The revision system allows you to see what changes were made in each revision by dragging a slider (or using the Next/Previous buttons). The display indicates what has changed in each revision. – and there may be others.

It feels to me that there is a disconnect here. All these new and ‘improved’ features seem to get hammered out and developed without accessibility really being thought about. Using trac tickets here to raise accessibility issues seems like trying to bolt the stable door after the horse has departed.

I think it would be a disaster if these new features are developed without some consideration for accessibility, and I’m sure we can all agree that it’s a lot more work to retrofit accessibility into developments. In fact sometimes it’s not really possible – when the design is so alien to accessibility.

I’d hate to see Custom Menus, Post Formats, Post Revisions become the next accessibility disasters – like Theme 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., and the new Add Media Panel.

Is there anything we can do to ensure that this doesn’t happen?

#menus, #post-formats, #revisions

Graham Armfield 9:46 am on January 11, 2013
Tags: , usability,   

User Videos – An Accessibility Angle

Over the last few months WP dev lessbloat has done a series of videos where he has invited in ‘real-life’ users to try out various features of the WordPress backend – and has videoed the experience.

I’ve watched many of these videos and read the transcripts of the interactions and they are a really great insight into usability, and assumptions that developers make about how much users understand about what’s expected of them. The most recent one is at: https://make.wordpress.org/ui/2013/01/09/two-more-menus-user-tests-focusing-on-this/

I’ve often thought that it would be quite revealing if somehow we could produce a series of videos of blind and motor impaired users trying out key bits of the admin area. These would highlight 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) issues perhaps more than words on a page could, and could constitute a powerful benchmark on which to base future improvements.

Does anyone else think this might be useful? And if so, how could we go about making some?

#testing, #usability, #video

Graham Armfield 12:07 pm on January 9, 2013
Tags: ,   

3.5 Media Manager Accessibility

Has anyone had a chance to test 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) of the new Media Manager that came in with 3.5? I’ve not had time yet, but I am worried that it’s not fully keyboard accessible.

#core-2, #media-manager