Presentation delivered at WordCamp UK - July 2013. There has been some progress on the accessibility of the WordPress admin screens in the last year. But there are some changes that weren't so welcome. In this presentation I talk about what's happened, and look at some ideas for a strategy to try to ensure WordPress becomes as accessible as possible.

1. Coolfields Consulting www.coolfields.co.uk
@coolfields
WordPress and Web Accessibility:
Where we‟ve got to, and where to next
Graham Armfield
Web Accessibility Consultant
WordPress Developer
graham.armfield@coolfields.co.uk
@coolfields

2. What I‟m Going to Cover
• Recap on last year‟s presentation
• What happened afterwards
• What shouldn‟t have happened
• The future of WordPress and accessibility
2

3. Coolfields Consulting www.coolfields.co.uk
@coolfields
Brief recap from last year
What was all the fuss about?

4. Recap on last year‟s presentation
• Slides are still available - http://owl.li/cfm7H
• What is accessibility, and why it‟s important
• Types of disability, issues and assistive technology
• A snapshot of WP accessibility
• WordPress core
• What theme and plugin developers can do
• What content authors can do
• Problems identified with WP admin screens
4

5. Accessibility problems with WP
admin screens in 3.4
Summary
• Many, many links – including seemingly empty ones
• Tab order didn‟t always make sense
• Some big problems for anyone who can‟t use a mouse
• Keyboard focus not always visible
Logging out
• Not possible without a mouse
• No visible log-out link
5

6. Accessibility problems with WP
admin screens in 3.4
Adding and editing posts and pages
• Accessing tool bar
• Adding images
• Tab order issues
• Lack of help/instructions
Widgets and screen options
• Accessibility options are provided for manipulating widgets
• But screen options were difficult to find for blind users
• Lack of clear instructions
6

7. Accessibility problems with WP
admin screens in 3.4
Custom menu builder
• Keyboard operability not good
• Could add items to menu…
• But could not manipulate
hierarchy
• Could tab to items…
• But no useful audible feedback
for screen readers
• Lack of meaningful help or
instructions - especially for those
with cognitive issues
7

8. Accessibility problems with WP
admin screens in 3.4
Theme customizer
• Keyboard operability very difficult – inc
for screen readers
• Couldn‟t tab into panel
• Focus not easy to follow
• Tab order could be better
• Selecting colours
8

9. Coolfields Consulting www.coolfields.co.uk
@coolfields
What happened afterwards
Good things…
and some not so good things

10. What happened afterwards during
10

11. Loads of accessibility trac tickets
Current status: owl.li/mMThL
11

12. 6
Progress on key issues
12
Issue Fix? Release
Theme Customizer All keyboard operable including colour picker. VR
use not so easy.
3.5
Custom Menu Builder Improvements for screen reader users and
partially for VR users.
3.6??
Links Skip links now present, but only visible when
receive focus. Many redundant links removed.
3.5
Log out without a mouse Log out link appears when receives focus, but
still not permanently visible.
3.5
Visible focus Much better in most places. 3.5
Labels for input fields in page/post
lists (eg search/select all)
Much better. 3.5
Screen options Much easier for screen reader users to find and
use.
3.5
Accessibility of quick edit panel Not yet. ???
Tab order not logical Much better. 3.5
And there are others…
4
4
4
4
4
4
4
6
6

13. Acknowledgements
So a lot was achieved in 3.5 and significant progress made
• Thanks go to all those WP developers who got involved
and actually made the changes that were specified.
@lessbloat, @sabreuse, @azaozz, @mattwiebe,
@MikeLittle, @SergeyBiryukov – and anyone I‟ve missed
• Also to Andrew Nacin who was the project lead on 3.5
and who was keen to ensure that as many accessibility
improvements as possible were included.
13

14. What happened next
• I contributed more to the Make WordPress Accessible
Group http://make.wordpress.org/accessibility/
• Other new people joined the group and contributed as
they saw that things were happening
• There is now a regular weekly IRC chat for accessibility
• Reworked accessibility page within the WP codex
http://codex.wordpress.org/Accessibility
• New accessibility theme review guidelines
http://codex.wordpress.org/Theme_Review#Accessibility
14

15. What happened next
So, everything‟s going along
swimmingly? We‟re there aren‟t we?
Well no, it‟s not all good news…
15
J
L

16. Add media panel
16
Something the accessibility team missed – new functionality in 3.5

17. Add media panel
• No labelling of the media for
screen readers if you could get
to them
• All media in one block could
mean hard work getting to the
Attachment Details frame
17
• Can‟t be used without a mouse
– no way to tab to the media

18. Add media panel status
• Trac tickets raised in February, but no action
for ages
• Eventually, Dave Martin (aka @lessbloat)
gave up some time to try an interim
solution using advanced ARIA techniques
• Not a perfect solution, but a better
experience for keyboard users, and users of
newer screen readers
• Unfortunately I believe the fix has been
pulled from 3.6
18
L
L
J
J

19. Coolfields Consulting www.coolfields.co.uk
@coolfields
The future of WordPress and
accessibility
A roadmap for the future…
and making it happen

20. WordPress for the world
http://memeburn.com/2013/05/matt-mullenweg-on-how-open-source-is-democratising-the-web/
20

21. Make WordPress accessible group
• http://make.wordpress.org/accessibility
• We are few
• We are all volunteers (AFAIK)
• Have to juggle our WP a11y effort alongside our client
work
21

22. Make WordPress accessible group
• Being totally responsible for the accessibility of
WordPress is not really feasible
• And it will not bring about change fast enough to
include some groups of people in the WordPress
„experience‟ for the foreseeable future – if ever
22

23. The „Us‟ and „Them‟ of accessibility
Being the „accessibility guy‟ doesn‟t always make you
popular
• We are the people who only find fault
• We are the people who only say “No, not like that”
• But I don‟t believe that any of the WordPress
accessibility group want that role
• We want to be a resource. To help and to bring about
change
23

24. The situation has to change
• WordPress can‟t go on just retrospectively applying
sticking plaster solutions to new functionality that is
inaccessible
• It takes too long
• It also leads to poor, half-baked solutions that don‟t work
for everyone and can be hard to maintain
• Accessibility has to be considered at all stages – design,
build, testing
• Which means everyone has to be involved
24

25. Design with accessibility in mind
Early proposals for showing
post revisions in 3.6
25

26. Build/test with accessibility in mind
Early proposals for
showing post revisions
26
Can I tab to
all these
links and
images?
Do these form
fields have labels?
Is the
colour
contrast
sufficient?
How do
these images
describe
themselves
to screen
readers?
Will I know if
they are
selected?
Can I tab easily from images
to attachment details?
How would I access these
with voice recognition?
Does all users know what‟s expected of them here?

27. An accessibility strategy for
WordPress?
Currently being debated on Make WordPress Accessible…
• An accessibility statement
• Further development of coding and style guidelines for
accessibility
• Providing resources
• Development of outreach programs for WordPress
developers
• Improving communication
• Theme and plugin reviews
• Appointing an accessibility lead
• Growing the accessibility group
27

28. Other people are doing it
28

29. Like to get involved?
We‟d love your thoughts
Make WordPress Accessible
http://make.wordpress.org/accessibility/
Codex page on accessibility
http://codex.wordpress.org/Accessibility
Theme guidelines: accessibility
http://make.wordpress.org/themes/guidelines/guidelines-accessibility/
Other ideas…
29

30. Thanks for listening –
any questions?
graham.armfield@coolfields.co.uk
@coolfields
30

31. Resources 1
• WCAG Guidelines - http://www.w3.org/TR/WCAG/
WARNING: Not all easy reading, but use the „Understanding
WCAG‟ section
• Accessibility sites and blogs (including my own)
• Webaim - http://webaim.org/
• Accessify Forum - http://www.accessifyforum.com/
• WebAxe - http://webaxe.blogspot.com/
• Coolfields (my own) - http://www.coolfields.co.uk/blog/
(including many guides to correct markup of forms, text for
screen readers only, etc)
• ARIA techniques
• Mozilla Dev Network - https://developer.mozilla.org/en-
US/docs/Accessibility/ARIA
31

32. Resources 2
• Validators and accessibility tools
• Markup validator - http://validator.w3.org/
• Wave - http://wave.webaim.org/
• Colour contrast analyser -
http://www.paciellogroup.com/resources/contrast-
analyser.html
• NVDA - http://www.nvda-project.org/
• Useful Firefox Add-ons
• Fangs (screen reader emulator)
• HTML Validator
• Web Developer toolbar
There is no tool that can fully test for accessibility
automatically – so much is about context.
32

33. Resources 3
• Other Useful sites
• Keyboard accessible dropdowns –
http://blakehaswell.com/lab/dropdown/deux/
Technique now adapted into WordPress plugin -
http://wordpress.org/plugins/accessible-dropdown-menus/
• HTML5 and Accessibility - http://www.html5accessibility.com/
• Subtitle Horse - http://subtitle-horse.com/
• Amara (Universal Subtitles) - http://www.amara.org/en/
33