Request: merge the Accessibility child theme into to Twenty Ten

Of course this would be the best way to get Twenty Ten fully accessible. It’s a pitty that WordPress default theme is not fully accessible. Now and then some of the problems are reported in Trac, but not always the best accessible solutions are chosen.

You can find all accessibility improvements in my article:
https://sprungmarker.de/2010/wordpress-child-theme-for-twenty-ten-accessible-1-0/

There are so few CSS-Todos and some in functions.php to get the theme more accessible. Some problems will still remain and one has to correct the templates. But on the first run I only wanted to get the most accessibility with minor changes (only CSS and functions.php).

I would appreciate it to get Twenty Ten at least more accessible (color, contrast, keyboard navigation, working skip-links, hidden headlines etc.). Thanks.

Sprungmarker has created the Accessible 1.0 child theme for Twenty Ten

Theme licence?

Of course this would be the best way to get Twenty Ten fully accessible.

Agreed and some work has already been done towards this. But getting changes into the core theme isn’t as easy as it might first appear for operational & technical reasons. To be brutally honest, the will & demand simply isn’t there. Even the wp-accessibility mailing list died a death virtually as soon as it was created.

Licence as every WP-Theme: Licence: GNU General Public License v2.0

Yes – I follow the a11y request in your trac core development and it seems right the same to me. And I got the idea that WordPress doesn’t have an real accessibility expert to get the theme accessible. Or the experts don’t want to get it running …

Even the skip-link which comes first with twenty ten (skip-links are so old as accessibility one might think …) is not implemented for keyboard use. There is a trac ticket for that and I think it is resolved. Why not put this accessibility enhancement in the critical update too?

Licence as every WP-Theme

Thank you. ??

The accessibility experts are there (it’s one of my specialist skills and I’m sure there are plenty of others with similar expertise).

Even the skip-link which comes first with twenty ten (skip-links are so old as accessibility one might think …) is not implemented for keyboard use.

It just need a CSS patch but as I’ve said, it’s been difficult to try and get these changes pushed through in a meaningful manner.

Why not put this accessibility enhancement in the critical update too?

I’ve been promoting web accessibility since 2000 and always build it into my themes but, even so, I wouldn’t class the access issues in Twenty Ten as “critical”. Medium priority, at best, I think. The theme, and WordPress, as a whole are pretty accessible as they stand. That doesn’t mean I think we should stop pushing for even better levels of accessibility. Just that we have to acknowledge that issues relating to security and functionality have to take priority.

In the meantime, there are other web devs out there – like myself – who are producing high accessibility themes. Twenty Ten isn’t the be all and end all. It’s just a good default theme with some access flaws.

Seems to be a hard process to get changes in a core update. ??

We could discuss if a skip-link is even needed cause there is not much in theme header to skip. But – if it is build in, it should work.
To define “critical” in a11y, hm, sure – twenty ten has no real blockers (okay, drop-down menue has for keyboard users), but it could be much more accessible.
One could get around this blocker never get to the second level navigation by putting the navigation again in one of the sidebars, but this is not the right way to get it running.

The things I “repaired” are not really “critical”, right. But they are essential in getting a website or theme really accessible.

Okay, there will always be devs out there who make a11y theme – but there are not really that much around. But: As Kubrick the default theme will get a lot around in the web and this could be websites who are – for the first run – really accessible. But allright, that was my impression reading the a11y development of the default theme the last years – it has no real priority. That’s why I made this child-theme. Maybe this is the real concept, to get the theme more accessible.

@esmi, @sprungmarker thanks for responding. One of real the issues I found when trying to find a theme suitable for a small business and that had good accessibility was that I just couldn’t find one. Perhaps I wasn’t looking in the right places but it’s not even a tag you can search on in the master themes list. I tried a few (like the old Beast theme) but my firsts test is simple keyboard only access. Accessible 1.0 was the only one I manage to find.

So all the points I made in the first post stand for me.

It’s great to have folks like you both working on the a11y issues, but it seems that, as always we, need to get above the noise and raise awareness. Devs are often only to happy to include a11y when they realise it means more happy users.

So how do we push harder?

I posted here as it seemed the right place, should I also email the dev list? Or will be get an OT response?

it’s not even a tag you can search on in the master themes list.

I did raise this as a possible tag addition a while back but the issue with an “accessible” tag is – how do you define it? Where do you set the bar? WCAG1? WCAG2? A? AA? And who do you get to audit each & every theme that is submitted with an “accessible” tag? An accessibility audit is not a simple 10 minute job and the theme review team is pretty stretched as it is.

Then – extend the issue beyond the Theme Directory to the users. With all due respect, a user can completely wreck even the most accessible theme and produce a site with all kinds of access barriers very easily. The very authoring & design tools that allow non-technical authors to run their own sites can be used to introduce all kinds of issues. The new custom background is a case in point. I wonder how many decent themes have been “ruined” by foreground/background contrasts that don’t get anywhere near the minimum contrast requirements. And don’t even get me started on patterned backgrounds!

Can you produce a WordPress site that meets all the access requirements? Yes – it’s been done. Is that site actually as accessible as it sounded? No – it isn’t. WordPress and the theme can only ever be one part of a pretty complex picture – which makes it that much harder harder to prioritise accessibility at the development level.

I would dearly love to see accessibility given a much higher profile but that’s not happened so far (and not for lack of trying). The whole subject – whilst generally popular superficially – is one that people do seem to have problems getting to grips with when it gets down to implementation. There are also so many other issues vying for attention that accessibility doesn’t seem to be able to hold anyone’s attention for any length of ti…oooh .. shiny jQuery thingy! ??

Might I suggest that, instead of trying to persuade core devs to devote spare time to the subject, it might be better to build up a strong WP-access group with the expertise and know-how to promote and submit practical patches?

Yes – to tag and control themes as acessible is a huge job. I agree.
Maybe you can make a possibility to put child themes in a directory? I know not every child theme is that interesting, but an accessible one would get an wider audience that way. I could not submit it to the themes directory.

The topic accessibility in WordPress is a complex process – tinymce, plugins etc. I agree too. But to get the default theme more accessible is one part of the process.

A WP-access group is a good starting point, even I would say it is only an add-on. Patches is that what I made with the child theme, but accessibility should not build that way. I think you will agree. And – many jQuery plugins are accessible, you have to search and choose the right one. ??

OK, yes it is hard to define what would be acceptable level of accessibility in order to get the tag. Ideally *all* would be accessible so the tag is not required, but that is like saying all themes should be usable and depends on users requirements. However there are some basics that should be address and could merit a tag to flag some effort.

>With all due respect, a user can completely wreck even the most accessible theme and produce a site with all kinds of access barriers very easily. The very authoring & design tools that allow non-technical authors to run their own sites can be used to introduce all kinds of issues.

Indeed thsi an issue with any CSM – you want to let users do what they feel like, yet keeps some constraints. You can use wysiwyg tools to help and could add tests but it all gets complex. However IMHO you shouldn’t throw in the towel and go for lowest common denominator in all the default framework code because you can’t control what users will input. Looking at the page mark up, it is of reasonable quality, so that has not been done for basic HTML. Why should the a11y of the default framework be different?

A a11y group is good suggestion – but i feel we need both actions so the core gradually improves. As you say someone needs to own a drive it so it’s stays on the agenda.