Temple Gate: An accessible HTML5 WordPress Theme
-
I’d just released an accessible HTML5 WordPress Theme, hope it’s of useful to those who need their blogs be accessible.
Find the download link in the first sticky post.
-
License?
It’s also failing WGAG2 AA on a couple of points:
– links to different resources with the same link text (“x Comments“)
– Content links are only perceivable by color alone (and, incidentally, you might be hitting red/green color blindness issues with your choice of hover/focus colors).
Very pretty header design.
Thanks for the comments.
It’s released as GPL license.
links to different resources with the same link text (“x Comments”)
In case I didn’t quite know what you meant, can you be precise and if it’s only for a certain page or entire site?
If I understand what you meant by the “x comments”, do you suggest that I should add something like this?
“x Comments to Temple Gate: An Accessible HTML5 WordPress Theme”
“No Comments to HTML5 Tags used in Temple Gate”
“No Comments to HTML5 markup examples for the theme”
Then hide the heading for desktop screen and show it for screen reader?
If yes, let see how screen reader reads it:
<article>
by (author) on 30 September 2010
x Comments to (article title)
Filed under: (category name)
(article title)
(excerptt)
tags (tag name)
</article><article>
by (author) on 30 September 2010
x Comments to (article title)
Filed under: (category name)
(article title)
(excerpt)
tags (tag name)
</article>It’s actually not too bad, not so much noise as the article title just got repeated twice in an article element. Could it help the accessibility for screen reader? My answer is 20/80. 20 Yes and 80 NO. The 20 is for people who are new to using screen reader; the 80 is for experienced screen reader users, and these are the users who most likely treat the extra article title as noise than accessible aid.
– Content links are only perceivable by color alone (and, incidentally, you might be hitting red/green color blindness issues with your choice of hover/focus colors).
That is not the best choice however I stick to my decision because the choice of colors are part of the design consideration.
Dotted red outline is used for :focus and it provides sufficient aids for keyboard users.This is however I evaluate accessibility:
1) failing a WCAG 2.0 point does not meant the site/a page/a certain element is in-accessible;
2) passing a WCAG 2.0 pint does not meant the site/a page/a certain element is accessible;
3) if a WCAG 2.0 point fails is there an alternative for user? Could the site/a page/a certain element still accessible? If a person with a disabilities still able to access the info with the assistive device? Do the decision I made make it impossible to navigate the site; Do the decision I made cause confusion to the user thus making it impossible to use the site?If I am building a site targeting colorblindness audiences, then I definitely will make sure the color choices are most accessible for their eyes. For site that target general audiences, there maybe different consideration.
I have myopia, I wouldn’t expect anybody aid my need, making everything 50px large so that I can read the text without a pair of glasses (assistive device). This is the same I view the colorblindness issue, I wouldn’t use the lighter gray or light yellow for content with white background as I view it as a failure on accessibility for the largest audiences. I make effort and try the very best to provide accessible website for the larger audiences, and I expect (small percentage of) people with disabilities take care of whatever they need to take care, not putting all the responsibility on website builder – this is the problem we have been facing for years. The WCAG guidelines assume the responsibility are all on the website builders, and this is the problem why most web designers are unwilling to embrace the accessibility. There are also accessibility issues that should be solved and must be solved by browsing/assistive devices yet some accessibility practitioners assume it’s their (and including web designers) responsibility.
It’s no wonder the web is full of inaccessible site for the larger audiences.
This isn’t a direct response to your comment on color issue but worth to mention.
IMO, common sense and learned experience can serve as part of accessibility feature.
Some link texts provide better clue than ambiguous link colors, and some, by its surrounding contents. In the case of this theme, “skip to content”, “Skip to content navigation” as well as “x comments” and “Filed under: category name”, “tags: tag name” provide better accessibility aids (by common sense and learned experience) than ambiguous visual cue like linked color.And this is something I take into account when I evaluate a potential accessibility issue.
Are you aware that screen reader users use Links and Header lists to navigate web pages? This feature in their software parses the page and extracts all Heading and Link text in separate lists on command. In this situation, links lose all context – so yes, identifying a unique resource appropriately is an accessibility issue. And it will affect experienced users too.
Dotted red outline is used for :focus and it provides sufficient aids for keyboard users.
Sorry but that is simply incorrect. And I speak from experience having been forced to spend over 6 months navigating sites using VR software. A dotted outline is extremely difficult to see in the context of a whole screen. A background/color change for the focus and active states makes a terrific difference.
If I am building a site targeting colorblindness audiences, then I definitely will make sure the color choices are most accessible for their eyes.
I’m curious – how exactly do you manage to ensure that no color-blind individuals visit your “general audience” sites? Web accessibility is not intended to be applied in special cases only. It’s meant for all sites. And that includes keeping the needs of color-blind users in mind.
This is however I evaluate accessibility:
That’s not the issue. The theme itself states:
Temple Gate WordPress theme is a HTML5, Section 508 and WCAG 2.0 quality theme
http://lotusseedsdesign.com/temple-gate/about/
If you’re claiming WCAG2.0 compliance, then it doesn’t matter what your personal opinions on the guidelines are, you have to follow them. If you don’t agree with some of the guidelines and do not intend to comply with them, don’t claim compliance. Simple…
The WCAG guidelines assume the responsibility are all on the website builders
Not true. The guidelines are intended to ensure that the page content is Perceivable, Operable, Understandable and Robust. They are intended to meet the user and the user-agent developers halfway. Not force the responsibility onto the web developer.
There are also accessibility issues that should be solved and must be solved by browsing/assistive devices yet some accessibility practitioners assume it’s their (and including web designers) responsibility.
I think you under-estimate how sophisticated the AT software has become. And how resourceful its users have to be to deal with some of the barriers they face every day.
Some link texts provide better clue than ambiguous link colors, and some, by its surrounding contents.
Surrounding content becomes useless once the links have been parsed into an independent list that is removed from any context. And links should never be indicated by color alone outside of a well-defined navigational area. The underline is there for a reason.
How much time have you spent with screen reader users, switch users, VR users etc? I would certainly be very wary of basing your design choices on your own experience with screen reader software unless you have first trained for at least 1 full month without any access to a graphical display. Anything less than that and your “experience” could do more harm than good. Far better to consult with expert AT users.
I am not at all interested in getting into debate with anyone who thinks I must do accessibility practice in <i> his/her way</i>, and I am certainly not in the habit telling others to do it my way or try to convince anyone to consider doing it my way. That being said, I am responding to the issue you raised so that anybody who sees this thread the first time, and consider to use the Template Gate, aware that the decision I made in regards to failing certain success criterion of WCAG 2.0 AA, is not out of ignorance; he/she can then make a decision whether it worths to waste a bit of time to entertain the idea of using the theme.
I am not a screen reader user that is apparent, I do test the sites I develop in screen reader with VoiceOver, though I don’t test on every site that I built sometimes dues to budget constraint, but the accumulated knowledge from the sites I tested, enable me to know what are to be concern with specifically with screen reader user; also, I have seen it in person how a screen reader user uses JAWS to browser the sites. Having said that, I am not ignorant in my craft.
First and foremost, the theme is built on HTML5; HTML5 outline algorithm can help addressing some accessibility issues (that are not available for sites that are built on XHTML and HTML4) thus improving the native accessibility for screen readers without adding redundant code by hiding it from desktop screen, then show it for screen reader. The support of HTML5 in most currently latest version of Screen Readers which I am positive, is somewhat lacking. This issue maybe solved by bringing in ARIA role to the theme, and this is something which will be added in the next upgrade of Temple Gate – it was in my personal roadmap of the theme but I didn’t feel I needed to tell anyone about it in my previous response; I don’t feel I need to tell anyone about it now either, but I thought it may worth mentioning it just in case I feel compel to respond to anything you may bring up.
In the case of comments link text (Success Criterion 2.4.4), the ‘article’ role of ARIA and ‘article’ element of HTML5 (if a Screen Reader supports this element) will help the user identifies that the “x Comments” is part of the given “(article title)”.
<article>
by (author) on 30 September 2010
x Comments to (article title)
Filed under: (category name)
(article title)
(excerpt)
tags (tag name)
</article>Putting the ARIA role and HTML5 outline algorithm aside and supposed the theme is built on HTML4 or XHTML, I will still stick with my decision.
Quote myself:
It’s actually not too bad, not so much noise as the article title just got repeated twice in an article element. Could it help the accessibility for screen reader? My answer is 20/80. 20 Yes and 80 NO. The 20 is for people who are new to using screen reader; the 80 is for experienced screen reader users, and these are the users who most likely treat the extra article title as noise than accessible aid.
Why I do it the way I do it?
a. The WCAG 2.0 guideline is a one-size-fits-all approach. Some Criterions are applicable for all situations and truly help the screen reader user; some criterions do not take into account that we human being are not robot and that our accumulated experience can quickly overcomes the so-called “confusion/inaccessibility” defines by the rigidity of WCAG 2.0 guideline, thus making the “accessibility-practices-of-good-intention” turns into bad accessibility.
b. Chances for the new/inexperienced 20% screen reader user to become experienced user like those in the 80% category, is 99.9999999% absolute. Quick learner will pick up the skill in less than few sites they surf to make sense that the “x Comments” link text is for a given article, and the next “x Comments” link text is for the second article; average users may take 10 or 20 sites of surfing; the slower learner may take much longer, but he/she will get there eventually [1].
b. Chances for those experienced screen reader users in the 80% category fall into the 20% category is 0.0000001%.
c. None of the screen readers I know of, provide a way to turn off the “redundant (information) hacked-accessibility” that you think must be provided to all screen readers, as such, this “good-intention-of-accessibilty” will become an usability issue to screen users who are in the 80% category because they are forced to listen to the same link text repeatedly. This creates similar usability issue with site that has music set to ON; worse thing is, the screen reader has no option to switch off the redundant information.
Is it discriminative to exclude the 20% user who has 99.9999999% to become experienced users like those in the 80% category ? Certainly not.
Is it OK to not provide “redundant (information) hacked-accessibility”? Under the consideration of C and B, certainly yes.
[1] Is it OK not to take the slower learner’s need into account? IMHO I don’t’ think anybody has real, right, absolute answer for it-I certainly don’t.
If you’re claiming WCAG2.0 compliance, then it doesn’t matter what your personal opinions on the guidelines are, you have to follow them. If you don’t agree with some of the guidelines and do not intend to comply with them, don’t claim compliance. Simple…
I am not changing anything in my content. If you have issue, feel free to file a complaint and have WCAG entity fires a warning to me that I must not used the “compliance” wording together with WCAG 2.0. If this is not a viable option, feel free to remove my original post from the forum so that no WordPress forum user is misguided by the “compliance” wording I used; if this also not a viable option, feel free to bash it wherever you can.
I can recognized that your heart is with accessibility, and I respect that thus respect everything you said, as such, I am also willing to offer this to ease your annoyance, that I am happy to add a “Temple Gate WordPress theme is a HTML5, Section 508 and WCAG 2.0 quality theme. Temple Gate WordPress theme is a HTML5, NOT A Section 508 and NOT A WCAG 2.0 quality theme based on the the rigidity of WCAG 2.0 guideline and based on (your name/website address (if any)’s standards.”
You yourself opened up the can of worms by claiming the theme is WCAG 2.0 AA compliant, you laid yourself open to criticism.
Your theme may be close to it, but it certainly doesn’t fully comply as you yourself even admit:
That is not the best choice however I stick to my decision because the choice of colors are part of the design consideration.
Dotted red outline is used for :focus and it provides sufficient aids for keyboard users.Which is fine, nothing wrong with it[1] – but you can’t then claim being compliant (why not use: mainly compliant or compliant with exceptions). In fact you currently have:
Built with Accessibility in mind, with section 508 & WCAG 2.0 AA compliant
all you need to do is remove the word compliant.
[1] excepting esmi’s argument of course.
Aled, make a theme yourself using what you just wrote there, it will be great, I’d love to hear about it, if you were to share or sell it? Chers. Al.
I found this thread while trying to look into accesible themes. I found alsd’s theme through a Google search and ended up in this thread while researching it.
Being that there are so many criticisms of his theme, can anyone recommend another?
Having to work on an accessible site for my first time, I appreciate his efforts. But as the other users mentioned, using terms like compliant if it’s not can end up causing issues.
[torndownunit] if you like his theme, by all means use it – better yet modify it so it works for you.
The only criticism I see going on in this thread is a “what if a blind man, with no hands, who had never seen a blog site before, who is also color blind and also dumb in the head and didn’t know he was colorblind, needed to read your blog and divulge information from it and was only willing to waste 3 seconds trying to figure it out before moving on to other popular blogging sites that he does not know how to use”.
Which, in case, almost every criticism is a joke – except for claiming you follow someone’s guidelines but don’t. Who cares.
Thanks,
ByeThe only criticism I see going on in this thread
Rubbish! The criticisms posted were valid and based on a combined 20 years worth of experience working in accessible web design.
Who cares
I do. And anyone else who works in this field. Accessible web design is far more than just catering for visually-impaired users. If that’s not a concept that you understand, then I suggest you take some time out to study the sector in depth before offering an opinion. Comments like yours have the potential to cause serious damage and mis-conceptions.
@torndownunit: Any of the themes I have developed should facilitate the creation of sites that comply with WCAG accessibility guidelines to AA or above. However, a theme can only do so much and a great deal depends upon content authors understanding the issues when adding site content.
Thanks, I am not actually specifically interested in his theme to be honest. It’s just one of the few you come across when searching for themes that claim to be accessible. The users above seemed very knowledgeable on the accessibility issue, so I thought they may have some theme recommendations that they think are better than the developers theme.
The person I am setting up the site for wants it to be accessible. So I just have to do what I can to find a theme that meets that.
esmi,
I was bouncing around between sites getting confused on on who I had contacted and who I hadn’t. I actually am interested in one of your other themes. I just sent a message from your site about it. I didn’t notice right away that you developed this one as well.
The users above seemed very knowledgeable on the accessibility issue
I was one of those who responded with criticisms. I’m also a theme developer with 4 free themes currently hosted in the wordpress.org theme repository and a few others hosted on my own site, http://quirm.net/themes
All of the themes are licensed under GPL2 and all should be accessible to at least WCAG AA/Priority 2.
- The topic ‘Temple Gate: An accessible HTML5 WordPress Theme’ is closed to new replies.