Core Development WordPress UI Forum Posts
Hey, all. I’ve updated the theme auditing guidelines and they have now been added to the theme reviewer’s documentation. Take a look at the requirements for the #accessibility-ready theme tag and comment back here with any suggestions or changes.
Note that these guidelines are in addition to the rest of the theme guidelines, and there are many quality guidelines already established that don’t need to be part of the accessibility audit.
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 accessibility by asking “Is there anything else we should be doing to make these dialogs better?”
My response to him was:
Does that sum it up, or is there more that could be added to that list?
Graham, please excuse my ignorance on this, but regarding Ticket #23295, there is a reference to using an iframe as a solution.
To work around that we can use an XHR instead of having an iframe (XHRs can be used to set cookies). Another technique is to create an iframe then submit a
It’s my understanding that iframes create problems for, at a minimum, screen readers…..
1. Is the assumption that an iframe creates problems for assistive technology a correct one?
2. Can an iframe be tweaked so that it is “friendly” to assistive technology?
3. If so, is that “tweak” part of the solution referenced in the ticket?
4. If not, is this significant enough to recommend against the iframe solution?
Thanks for EVERYTHING
Every (pseudo-)popup must close when the user hits ESC.
In this particular case the “popup” warnings/dialogs cannot be closed without making a choice/selecting an action. For the “post lock taken over” dialog there is only one action possible (for now?) but it shouldn’t be triggered by escape imho.
All three warning dialogs (post locked, post lock taken over, login expired) are modal as the user is required to make a choice or perform an action. They don’t have a “Cancel” option.
I agree that these options shouldn’t be avoidable; adding a method to avoid the decision would not help anybody. That’s not an accessibility issue, it’s a workflow issue, and the workflow requires that the user receives information about the change of state in the application and makes a conscious decision what to do about it.
But, for any modal contexts that can be avoided, being able to close via the esc key is a standard key mapping and should be available, certainly.
Not an essential feature, but a “nice-to-have” one: any image-links used to close the popup could have alt text of “Return to [page/section name]” or similar, instead of “Close”. Close is not as meaningful if you weren’t aware that anything had opened, while “return to…” makes more sense when you’ve temporarily stepped out of the normal task flow.
You might want to consider installing the MP6 plugin to get a sneak preview of the new user interface. Thus far, I’ve noted 3 areas of concern:
gogreener, and 3 others are discussing. #888
Can you make trac tickets for each of these?
I don’t think Trac is the right place for things specific to MP6 as a plugin – it’s not in core, and it’s not being developed with 3.6 in mind. It’s a little distracting, I don’t think MT/other contributors are looking for feedback there, and we can’t really say that something got fixed against a given milestone. I’d say stick to their office hours or Make UI for now.
With my limited understanding of accessibility issues, there’s much for me to explore, but as someone with some training in Art, I can say that, in terms of visually “signaling” that this part of the screen has a different functionality from the rest of it, this is an exponential improvement. I hope we can keep this.
…sorry, the point above to mean, I think this will help those with cognitive disabilities……as far as the application towards those with other disabilities, I am still investigating.
We had a little mix-up with the meeting time this week, due to the change to Daylight Savings Time in the US, so this meeting report may be a little shorter than usual.
However, the weekly meetup time remains at 20:00 UTC until the end of the month — when we may review and adjust it. Remember that you can convert UTC time to your local time at Worldtimeserver.com.
If anybody has a chance to take a look at the progress on autosave and post locking that would be valuable – I have some concerns about whether the context changes when sessions have expired will be announced, but haven’t had time to test it at all. Ticket 23295
Just lodged a general note of concern on the ticket. We really do need to test this out with our screen reader users.
I have made some comments on #23697 (Check and refresh post locks with heartbeat) also. There’s a proposal for a couple popup to be generated where locking conflict is occurring. I have asked @azaozz to confirm that focus will be moved into any popup that gets generated, and that focus goes somewhere sensible when a button is actioned.
I think I’ve finally finished! *gasp* Thank you to everyone who provided earlier feedback and jogged my memory.
Is there anything on the completed page I need to re-word or explain in more detail?
As previously, please post all feedback here rather than on the draft page itself.
that content must:
needs a ‘be’. Also with a list that each part concludes a thought, no : is required, use periods at the end of each item title to tie them to the beginning clause.
This is a really great resource! Thanks @esmi.
A few thoughts:
1. Maybe I’ve been doing this wrong forever, but it seems that the “good read more” code snippet could be simplified a bit:
<?php printf( __('%1$s – read more’, ‘theme_text_domain’), get_the_title() );?>
I also wonder if this technique deserves mention. It’s weird but I’m planning on using it in future themes I build.
2. There’s no mention of motion issues. Almost every slider I see these days has accessibility issues including slides advancing too quickly, text embedded in images without alt text, no keyboard navigation, no play/pause button provided, etc.. I wonder if those issues, particularly speed/motion,deserve mention.
3. This could take people down a wormhole, but I wonder if citing appropriate WCAG standards might add a bit of muscle to the points.
it seems that the “good read more” code snippet could be simplified a bit
I added the extra variables so that developers could use the generated span to hide the first part of the link off screen – if that was preferred. Personally, I do think it reduces screen clutter by a fair amount whilst still supporting screen reader users.
There’s no mention of motion issues.
They’re under “Things To Avoid – Autoplay & Animations”.
I wonder if citing appropriate WCAG standards
I’d rather not get down to the level of citing specific WCAG criteria in the main body of the page for a couple of reasons:
That said, I was wondering if I ought to include some more specific WCAG links in the General Resources section.
Wow. Totally missed the autoplay & animations section. Not sure how. Sorry ’bout that.
However, what this does make me think of is whether it might be worth adding a “common features with common accessibility problems” sections that references the relevant sections. I wonder if a theme developer would blow past “link text” but latch on to “read more links.” Same think with slideshow sliders. Of course this list couldn’t be exhaustive, so it might be more trouble than it’s worth and could lead to your fear of checklisting themes for accessibility, which I share.
Do you think a warning against using tables as layout for forms (or other) should be mentioned?
Wow! What a great resource this is. It covers a lot of ground, and I like how you use a few very basic concepts at the beginning to encourage developers to think along those lines and then also give lots of specific examples later of the way they are implemented.
I also learned from this document. For example, I always spawn new tabs because I find that much easier for me when I use websites, but I didn’t know this causes a problem for people who use screen readers. (I’m not sure what to do about this. Maybe I will decrease my use of them a lot and then include a link to get back to the original post?)
I liked the example of the Japanese cartoon sending kids to the hospital. It makes it very concrete. I have noticed that slideshows on autoplay are more and more common. My independent living center has an autoplay slideshow on their website now! [head::desk]
A typo: “And do not play any sounds with the user’s express permission.” I think you mean “without” permission, yeah?
Thank you for all your hard work and the care that went into this.
HTML5 longdesc attribute: Since this can fall under our umbrella, should we add this to the “theme development” section?
(First public working draft today): http://www.w3.org/TR/html-longdesc/
Nope. AT support for longdesc is very limited to non-existent. right now. I really wouldn’t bother using it — let alone ever relying upon it. Maybe re-visit it in a a few years to see if support has grown as HTML5 support increases?
Makes sense. Just wanted to cover all bases.
May I suggest Total Validator http://www.w3.org/2001/sw/wiki/TotalValidator as another useful tool for checking accessibility. From my experience with it I can say it makes correct checks (no false positive warnings) and they updated it regularly.
Oh – yes! I’d forgotten that one. I recently tried it out on a large site audit and was pleasantly surprised just how well it performed. I’ll add it to our list of useful tools.
Hi @esmi, thanks for posting these excellent guidelines for theme developers!
All these guidelines and tips are also very useful for plugin developers.
I hope the developers of the major plugins and frameworks take the time to read this.
Maybe a note at the top to encourage reading: everything that’s good for accessibility is good for SEO too
Some of my thoughts on the post:
Move Validation to the top of the list ( if only plugin developers would validate, life would be so much easier..)
Images:
In stead of decorative images (null alt) write
decorative images (alt=”")
Readability:
typo Tthe (second bullit)
Form Markup:
I didn’t know this: “any text that uses plain
tags may be ignored”
Can’t text be put in any other element then label or input inside a form?
Readably:
Quote: If you are using custom fonts, embed them in your theme so that you are not relying on a 3rd party site for font delivery.
Maybe only say :
“If you use a 3rd party site for fonts, check that the text is still readable if the fonts are not available.”
The fact that some fonts are hosted 3rd party is no accessibility issue on it’s own. (I use Google fonts a lot.)
The anchor link to the color blindness simulator doesn’t work.
Cross-Browser Testing: Add Chrome to the list?
Another small but lively meeting. We also had the opportunity to welcome our newest member, @shaun_10up – a relatively new core contributor. I think we’ll be keeping him busy over the next few weeks! 
Thanks to contributions from @lessbloat, @ceo and @quanin, we’re now seeing real, positive, progress on Trac ticket #14045. This greatly increases the chance of WordPress 3.6 being shipped with a more accessible custom menu system. Thank you for all of your hard work on this.
As part of the larger WordPress documentation project, I’ve put together a very rough first draft of an accessibility section for the theme developers’ handbook. It still needs a lot of fleshing out as I’m approaching this from the perspective of someone who doesn’t know anything about web accessibility. So I feel that we need to not only tell theme developers what to do but how and why.
That said, is the draft missing anything major — bearing in mind that we do not want to overwhelm theme developers?
Of course this is awesome, but in your guidance for POUR criteria, what do you think of making specific reference to the need for a:focus on items? I know that I thought I was conforming to ADA requirements before joining this group, and have come to understand its importance.
I think too, that knowledge is spreading because of the discussions in this group. For example, take a look at what Helen said about CSS and the impact of using display:none in this ticket on JQuery. We really need to thank her (as well as the other developers).
The point is, that the information, when made available, is spreading and doing good–for me personally, the simple knowledge gained about the importance of a:focus has had tremendous impact on my styling, and maybe we could impact others in the same way if we put specific mention of a:focus through these guidelines.
Just a thought, from someone who’s still learning a LOT!
Also, would it be too much to add specific mention on title attributes? Title attributes WAC blog That’s another thing that confused me greatly, and something I made a point to include before joining this group and learning the things I did. And again, I think the information is spreading.
would it be too much to add specific mention on title attributes?
Nope. Added. I’ve also left a comment on Trac ticket #23250.
Also, what about a way to increase font size if necessary?
And regarding color, I’m given to understand that it’s not just about color contrasts, but about color schemes too. Black text on a white background has great visibility, but is actually TOO hard to read for some people–white text on a black or dark blue background is easier for some people to read, though technically speaking, the contrast is not as great.
I’d argue that, these days, this is best left to the user agent, Most current browsers have a decent Zoom option and I think there’s a point when the individual user has to take responsibility for learning how to use their own software. Plus, there are some plugins that can handle this.
That said, should be still be pushing theme developers away from using pixels to define font sizes?
I absolutely agree that theme developers should not be using pixels to define font sizes….it’s a fundamental design issue in today’s modern pages.
Zoom doesn’t work well with images, and you have to set it on every page. People who cannot read tiny fonts use a setting for a minimum font size in their browsers usually (mostly between 16 and 20px).
An accessible theme should not break in these cases.
Doh! I forgot to make the “point” about all that talk about color schemes—-which is, should an option for choosing different color schemes be considered?
I’d argue that this is beyond the remit of the average theme & is best left to specialised themes or plugins.
what do you think of making specific reference to the need for a:focus on items?
Thanks for the reminder. I’ve added this to the Links section which is now broken down to cover text, highlighting and underlining.
In the section on Links, I think it’s worth mentioning that it is acceptable to hide the article title in a ‘read more’ link, as long as the method of hiding leaves the text available to screen readers. I think that there’s an issue with developers leaving this text out completely because they don’t want to see it, and don’t understand that it really is only necessary for non-visual users, and does not need to be displayed.
Also, it’s worth noting that under most doctypes, ARIA attributes will cause validation failures, but it’s more valuable to use ARIA than to be valid.
Added.
It’s a good start! But you have to look at how it can be done and should be done, not how you would do it.
You also have to add examples on how it could be done and when it’s done wrong, you could also add a link to another reference that explains it more detailed, for example w3.org, developer.mozilla.org, whatwg.org.
When you say that this is for the theme developers, you mean people that know HTML, CSS and/or more stuff(php, javascript, jQuery and so on) or are you aiming for the people that don’t know basic HTML and CSS?
Also drop the screen reader thingy, I would not recomand a newbie theme developer to start with screen-reader-friendly themes.
When you say that this is for the theme developers, you mean people that know HTML, CSS and/or more stuff(php, javascript, jQuery and so on)
Yes.
Also drop the screen reader thingy, I would not recomand a newbie theme developer to start with screen-reader-friendly themes.
Sorry? This is about how to create a more accessible theme. And that means including access for screen reader users. You can’t “drop it”!
Also drop the screen reader thingy, I would not recomand a newbie theme developer to start with screen-reader-friendly themes.
Uh, that would basically defeat the purpose entirely of making a theme accessible if you didn’t work towards making it usable via a screen reader. That’s like saying you want to build a theme that can be viewable on mobile devices without making it responsive.
I’d recommend adding “skip links” as important – especially for blogs with sidebar navigation. (apologies if wrong place to comment, first timer)
Goodness – how did I miss that out!
Also, what about document size and accessibility? Unnecessary markup, script bloat, site-wide function calls, and heavy design imagery reduces accessibility due to extra-long load times.
Hmm… I’d argue that these are really usability issues as they can impact upon anyone — as opposed to people with a specific disability.
Everyone, please meet andyvaughn who just joined the group and I notice he’s jumping in feet first:-) Welcome Andy! Andy connected with us via Twitter account @WPAccessibility which I am using to publicize our efforts.
Welcome, Andy Check your email for an invitation.
One addition: Themes must not use accesskey and tabindex attributes in front end or back end.
To create a predicable tab order write proper markup.
Both already added
Following up on the original post about the Add Media panel, here’s a quick rundown of the functionality issues with screen readers:
I’m sure there are other things that can be added to this list that I’ve missed. (Feel free to edit this as necessary, @grahamarmfield.) Unfortunately, while compiling this list my JAWS went berserk, giving me a bunch of installation errors and then my computer crashed.
As usual, we had a lively meeting. Thanks to all who attended.
The accessibility of custom menus in WordPress 3.6 and its related Trac ticket continued to be the main topic of conversation. This is undoubtedly going to be a very difficult area to get just right — not only in terms of the coding approach but also due to the problems of ensuring that screen reader users are presented with a meaningful construct when they try to manipulate menu items. Because of this, it was felt that there was a real danger of theoretical discussions taking priority over the development of prototypes. To try and avoid this, @GrahamArmfield and @lessbloat have agreed to take the lead together on developing prototype solutions.
@GrahamArmfield recently raised some concerns over accessibility issues within the current Add Media Panel and we decided to progress further with this. @ceo agreed to post a summation of the issues faced by some screen reader users shortly. Some possible new options were suggested such as an ability to tag images and filter the library by tag or an option to filter the library by upload date. Both may offer some benefits to users trying to locate a specific file in a large library when they are unable to “see” the images in question.
Finally, a reminder that we are still a relatively small group of active members (although we have 156 people subscribed to this blog by email). We do need more active members – both technical and non-technical. So do please consider joining the group.
FYI, There’s an interesting audio report on the accessibility issues of nested menus, whether ARIA works with VR systems, and more:
Audio interview concerning accessibility issues
For me, this particular audio report brought to light a lot of the difficulties behind ticket #14045
_Redd, and 1 other are discussing. 
_Redd 5:49 pm on March 19, 2013 Permalink |
You ROCK! As do these guidelines!
Do you think a requirement to have controls for audio, video be included in the guidelines?
Joe Dolson 5:55 pm on March 19, 2013 Permalink |
I’ll be honest, I find it extremely unlikely that a theme that had autoplaying video or audio with no controls available would ever be accepted to the theme directory. It’s also possible that including any kind of video/audio player crosses the Presentation/Functionality guideline, and wouldn’t be allowed regardless. I’ll check on that.
esmi 5:02 pm on March 20, 2013 Permalink |
What about sliders? Should they start automatically?
Joe Dolson 5:22 pm on March 20, 2013 Permalink |
Perhaps adding a generic statement addressing the behavior of media resources, to the effect that media resources should not, by default, auto start or change without user intervention. Would that cover these grounds effectively?
esmi 7:38 pm on March 20, 2013 Permalink |
Yes – I think that would work.
GrahamArmfield 6:32 pm on March 19, 2013 Permalink |
Nice piece of work Joe.
I have a couple of comments:
Hope that helps.
esmi 5:03 pm on March 20, 2013 Permalink |
1. We’ve got a load of links here for useful tools, so perhaps a link back to the page on this blog would be the best way forward?
2. Did you mean negative tabindexing?
Joe Dolson 5:25 pm on March 20, 2013 Permalink |
I think that a link back here for testing resources is a good plan, and I also agree that tabindex=0 should be allowed on non-focusable elements. Tabindex of -1 is already permitted.
Joe Dolson 10:06 pm on March 20, 2013 Permalink |
I’ve added comments regarding media resources behaviors, tabindex equals zero, and a link back to the Useful Tools page. That should cover everything discussed here; but let me know if you have more comments!
joe 10:45 pm on March 24, 2013 Permalink |
I love the accessibility-ready tag. Hits the right note and reminds the user that a11y is not a checkbox or developer only task. Should there be some ability to add specific alt text to a heading image, in particular if the theme supports multiple header images displayed randomly. not all images are decorative and empty alts on headers isn’t very a11y.
James Craig 6:52 pm on March 25, 2013 Permalink |
A few more pieces of feedback:
1. A “skip link” should not be required if the author uses WAI-ARIA landmark roles.
2. Forms section should require use of @required or @aria-required, and should encourage use of @aria-invalid while displaying field validation errors.
James Craig 6:57 pm on March 25, 2013 Permalink |
Looks like my first post didn’t go through. If you’re intending to use those bolded keywords as normative RFC-2119 requirements you need a few changes:
1. Add a normative requirement section explaining that. e.g. http://www.w3.org/TR/wai-aria/normative
2. Consistency case them. e.g. “MUST NOT” not “must NOT”
3. Change the passive requirements to active ones clearly indicating to whom the requirement applies. e.g. “Theme authors MUST include alt values for images.” not “Images MUST have alt values.”
Léonie Watson 2:40 pm on March 26, 2013 Permalink |
Great to see accessibility in the theme guidelines Joe.
I’d be inclined to rename the “Skip links” section to “Keyboard navigation”, and make the content less technique specific. For example:
“Themes must include a mechanism that enables people to move to a particular area of the page using the keyboard. For example ARIA landmark roles or a skip link.
ARIA landmark roles for banner, main, navigation, complimentary, search and contentinfo should be included. If the ARIA main landmark and navigation roles are used, a skip link need not be included.
If a skip link is included it may be hidden off-screen initially, but must always be available to screen readers and must become visible onFocus for sighted keyboard users.”
Joe Dolson 3:15 pm on March 26, 2013 Permalink |
Hey, James and Leonie — I’m not sure I’m comfortable with removing the skip links requirement if WAI ARIA landmarks are provided. While WAI-ARIA landmarks are great for screen readers, they don’t provide any navigation benefit for sighted but keyboard-dependent navigators, that I know of. If there’s something I don’t know there, however, please do let me know!
In terms of any RFC-2119 factors, I think that’s an issue for the WordPress documentation team to address — the entire document is quite inconsistent on all points, so it’s no great benefit to a single section conformant. But we can raise the question.
The voice change is a good suggestion, however – thanks.
Rian Rietveld 9:02 am on March 27, 2013 Permalink |
Great work Joe!
My comments:
1. About the Headings: maybe replace “use a reasonable heading structure” for “use a semantic heading structure”.
2. Add links to examples (like solutions of the read rome…” link or how place text offscreen), in stead of a link to a list of links that link to pages with links. Some developers (like me) are more comfortable with a quick example instead of reading though a lot of documentation first.
3. About the Headings, maybe replace “use a reasonable heading structure” for “use a semantic heading structure”.
4. I can see the HTML code for the abbr HTML also for CSS.
5. I agree with your opinion: “I’m not sure I’m comfortable with removing the skip links requirement if WAI ARIA landmarks are provided”. Leave it to the user what way to navigate, not all users of screen readers use roles.
6. Maybe add a requirement that inline style for mark-up should be avoided.
Joe Dolson 3:04 pm on March 27, 2013 Permalink |
We actually want to explicitly avoid requiring semantic heading structures, because the movable content model in many WordPress themes makes that almost impossible to guarantee — and the most important thing, ultimately, is having headings used correctly, rather than having a proper semantic structure to the headings. Developers are certainly encouraged to exceed the guidelines, but the guidelines are really intended to be fairly minimal.
Adding links to examples in some cases is intended — but will be developed over time.
I’ve noticed the HTML issue in the docs; it’s in markdown, and I’m not fully comfortable with what it supports yet…
We feel that inline styles are ultimately a code quality guidelines, and should be dealt with in the ‘Code Quality’ portion of the theme review, rather than in the Accessibility guidelines. Inline styles are not, by themselves, an accessibility problem, as far as I understand.