Tag Archives: keyboard

Graham Armfield 11:48 am on March 24, 2014
Tags: , , , keyboard, voice recognition   

Digital Accessibility Centre Visit – Part 1: Introduction, Keyboard and Dragon Testing

On February 25th 2014 I was honoured to visit the offices of the Digital Accessibility Centre in Neath, South Wales, UK. The trip was organised by fellow wpa11y team member Siobhan Bamber.

This post is the first in a series of three which summarise the feedback we received on using WordPress from three users with impairments. Our first session was with Becs who uses Dragon NaturallySpeaking (voice recognition software) and does keyboard 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) testing.

 

Continue reading →

#accessibility, #assistive-technology, #feedback, #keyboard, #voice-recognition

Graham Armfield 10:31 am on April 4, 2013
Tags: , , , keyboard, , ,   

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

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

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:01 am on February 25, 2013
Tags: , , , keyboard,   

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