alsd

Hi, thanks for the reply.

It’s a theme for public therefore I would like to make it less laborious for user, e.g. user can enter just the image name without month and date as the url or baseurl can take care of it.

But I do see your point, and the reason why WPP doesn’t prepend anything to the image path especially if the image is from external source (in my case I have a different custom field for this purpose).

It doesn’t matter. Microformats can take all the time it wants to include something to the spec, and HTML5 can take all the time it needs.

What matter is: “White space characters are not permitted within link types.”. It’s clearly written in the HTML4 Spec. In W3C site the most frequent used wordings are “may”, “should”, “may not” and ”should not”. When “not permitted” wording is used, it means what it said according to the spec, and there is no “may”, “should”, “may not” and ”should not” for interpretation.

The value of this attribute is a space-separated list of link types….So … great w3 is contradicting themselves. ??

English isn’t my tongue language so I do read the spec more literally, and read more into it with “space-separated” vs “space separated”. The usage of “-” literally indicates the white space (if any) will replaced by a hypen. There is no contradiction.

What esmi said about HTML5 being experimental, in another word, is that it’s an error caused by HTML5 validator and that it’s not a abuse, not a issue (meaning it’s correct in HTML4 and XHTML) – by saying so he/she lightly discard my report. And I do have a tiny bit issue because :1) I did my homework (cross-checked with HTML5, XTHML, HTML4 and Microformats) before I made the post; 2) I don’t know what kind of power a moderator has – this is “Requests and Feedback” forum and I don’t know if any WordPress team read the post or not, or if there is a screening procedure that first needs to pass through the moderator before it gets the attention from the WordPress team. If there is a screen procedure, it’s very bad for the users and for WordPress if the moderator takes a feedback lightly without doing his/her homework thoroughly.

HTML5 being experimental as esmi said it, has nothing to do with “White space characters are not permitted within link types.” REL attribute is not a newly invented element in HTML5 nor in Microformat, HTML4 clearly indicated that “white spaces are not permitted” and it will not changed in HTML5 or HTML6 50 years later.

Thanks for the info on the core.trac.www.remarpro.com, I was not aware of this place and didn’t know I can use the same user account to file bug report. Next time I sure will go to the right place.

FYI, I only posted the above link (html4) because esmi posted it.

My thought is WordPress uses it for both XFN and Microformats In HTML5. You don’t ever find white space in rel or any link type in any of the references, if you ever see web developer using it, it’s wrongly used. Tag keyword is in the HTML5 spec while category isn’t, though it’s not to say we can’t use ‘category’ but we can’t use it in a single rel attribute.

HTML5 Validator isn’t incorrectly flagged it because it’s experimental; it flags it as error because it’s wrongly used – the spec doesn’t allow two separate elements in a single rel attribute. Using PHP to get rid of the white space or substitue it with a ‘dash’ defeats the purpose of XFN and Microformat for the rel attribute because “categogerytag” or “category-tag” provides no semantical meaning.

https://www.w3.org/TR/html4/struct/links.html
rel = link-types [CI]
This attribute describes the relationship from the current document to the anchor specified by the href attribute. The value of this attribute is a space-separated list of link types.

https://www.w3.org/TR/html4/types.html#type-links

Authors may use the following recognized link types, listed here with their conventional interpretations. In the DTD, %LinkTypes refers to a space-separated list of link types. White space characters are not permitted within link types.

I think this should give everyone enough info to search the HTML5, Mircoformats, XHTML and so on…and what I wrote above stand.

“White space characters are not permitted within link types.”

I am here to report a bug/an abuse or rel attribute, not here to argue with anybody who wants to be right. Hopefully the persons who are in charged of the WordPress core know better.

Please read up the rel attribute in HTML4, HTML5, XHTML and Microformat and double check the code I posted if you really interested in this issue.

wrong: rel=”category tag”
correct : rel=”category-tag”
correct : rel=”category”
correct : rel=”tag”
correct : rel=”no-follow”

I posted the validation error, even if it passed the validation error it’s still WRONG! The issue is not about the validation error; the code generated is being abused because it doesn’t consider user may want to assign more than one category or moren than one tag to a post. In this case, even just one category assigned it still inserts two tags and it’s wrong because :

1) a rel attribute can has only single word, it must not has space;
2) if the space is removed using PHP, it defeats the purpose of using the rel attribute in this area because “category-tag” has no semantical meaning.

A code like this will further prevent web developers from using attribute selector because no browser can interpret it when a space is presented.

Correct: a[rel~=”catgory”] {color: red}

Wrong: a[rel~=”catgory tag”] {color: red}

Validation error or not, don’t know what it has to do with HTML5 not being formalized or the validator being experimental.

If you are really interested to dig in more,

I suggest you read up the rel attribute in HTML4, HTML5, XHTML and Microformat and double check the code I posted, find out where has gone wrong. It will help you understand better.

Wow. I thought I had long moved on from this thread.

20+ year experience in web design + first time user looking for a accessibility theme. A perfect marriage. Nobody can beat that! No even the most progressive accessibility practitioners that I know of (such as people from WebAIM) who have the insight and extensive experience in AT to see beyond the wcag2 guideline and use common sense to make sites for users, not for the guidelines.

p/s. torndownunit, I think you are truly confused. You sent the message to me via my site’s contact form asking about my themes. Now that you have found a with 20+ years experience accessibility diva to help you with your perfect accessible theme, therefor I shall humbly ignore your enquiry.

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.”

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.

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.

OK, I found the problem. It does work.

Once the menu added to menu area, you need to drag the menu bar, up/down for horizontal position, left/right for hierarchy. “‘depth’ => 2” prevent user to use the 3rd level.

Ah yes! Thanks for doing that for me! I didn’t even notice there is an option to change a thread status.

Sweet and simple! Thanks a lot!!

HI Adeptris,

Thanks so much! It works and thanks for the include_once tips.