rel=accessibility

While I was on my holidays there was a storm(ette) about rev=canonical and how it isn’t possible in HTML 5 because rev isn’t in the spec. (Apparently, the answer is to use rel=shortlink instead).

Mark Pilgrim published an article about link relations in HTML 5 with more information about the rel attribute, which I found interesting; I had no idea that relations such as rel=license and rel=author were available to allow auto-discovery of license information, and author details.

So I want to float the idea of rel=accessibility that would allow assistive technologies to discover and offer shortcuts to accessibility information, such as a WCAG 2 conformance claim, or a form to request content in alternate formats (for example).

The reason this would be useful is that links to such pages are generally right down in the footer of the web pages. This means that, for screenreader users, they have to navigate to the end of the page to find the link, or not know it exists.

Ironically, on sites that really do need a link to accessibility help (because of lack of structure to navigate with or huge amounts of content before the footer), those who need it are unlikely to find the link to the help.

In the “bad old days”, helpful developers would give an accesskey attribute to that link (which are generally undiscoverable to the human or to a parser, and which often conflict with assistive technologies’ command keystrokes).

A standardised way of indicating the related accessibility information would be better and not rely on arbitrary keys chosen by a developer.

So, should I propose that rel=accessibility be added to the list of values? It looks to be an arduous process; although you don’t need to prove your worth to the HTML 5 gatekeepers, you do have to prove your worth to the microformats gatekeepers.

I thought I’d ask you guys first—is this a good idea?

58 Responses to “ rel=accessibility ”

Comment by AlastairC

I think the key advantage is that it doesn’t need navigating to.

The key problem is not so much the link-rel, but what you have at the other end. That’s gonna be a fair amount of work.

Comment by Jeremy Keith

Sounds good to me. And I don’t think the process is as arduous as you fear.

The most important thing to do is get people using the value on their websites (shouldn’t be too hard to do). Then you can document the usage on the brainstorming page for your proposal (you can create a page for rel-accessibility from here: http://microformats.org/wiki/existing-rel-values#brainstorming).

I’ve added it to the WHAT-WG page: http://wiki.whatwg.org/wiki/RelExtensions

Comment by Jared Smith

I like it. The problem is going to be getting assistive technologies to do anything with it. But, if we always relied on screen reader support we’d be stuck in Suckville forever, so I don’t see this as a barrier to moving forward with it.

Comment by Otra de enlaces de accesibilidad y uno de economía - Areia.info

[…] rel=”accessibility” en HTML 5: al bueno de Bruce Lawson se le ha ocurrido añadir el valor “accessibility” a la propiedad rel en la especificación de HTML 5 al igual que existen los valores “author” o “license”. De esta forma, al igual que hay motores de búsqueda de referencias bibliográficas que utilizan estos valores, los lectores de pantalla y otros software de accesibilidad podrían hacer uso del valor “accessibility” para buscar directamente páginas con la información de accesibilidad y evitar así a los usuarios de lectores tener que buscar este enlace entre toda la maraña de enlaces de la página. […]

Comment by kazu

What is “accessibility information”? Is the info machine-readable and useful for assistive technology? Do you know any example of actual implementation of such technology? If no example yet in real world, I’m doubtful for providing such “accessibility information” via @rel.

Comment by Bruce

Kazu – Accessiiblity information could be a WCAG 2 conformance claim. It could be a link so the user can request information in another format (so if they can’t use PDFs, for example, they can mail to ask for the source Word doc or audio versions – very common for corporates, see http://www.sra.org.uk/sra/accessibility.page).

The resulting information doesn’t need to be machine readable (in the same way that contact or license information doesn’t). The important thing is that the link is machine *discoverable*.

Comment by kazu

Thank you, I got it – still I’m not sure such information helps people to use the content though. People do know how it is accessible via the content, rather than such information/statement I guess, so.

Comment by Angela Hooker

I think it’s a great idea. Though the battle will be encouraging people to post truly helpful accessibility information on their sites and not the typical canned accessibility statement with no follow-up.

Comment by Ben Millard

A link whose text contains the word “Accessibility” is already the standard way of doing this:

1. New UI nor processing from UAs or ATs.
2. No changes to user behaviour, either.
3. Appears in a “List of Links”.
4. Works with “Find in Page”.
5. Trivial to add to existing websites.
6. Visible when using a website casually.

In contrast, rel="accessibility":

1. New UI and special processing from UAs and ATs.
2. Changes user behaviour.
3. Does not appear in a “List not Links”.
4. Does not work with “Find in Page”.
5. In the best case, slightly less trivial. In the common case, requires editing HTML manually. In the worst case, a CMS can make this kind of change impossible.
6. Is not visible when using a website casually. (Thus likely to be get used wrongly by developers.)

I think rel="accessibility" is a stupid idea to a problem which doesn’t exist.

Comment by Ben Millard

Oops, a few corrections to my message:

* In the first list, item 1 should start: “No new UI”
* In the second list, “List not Links” should say: “List of Links”.

The sites most in need of providing alternative services for disabled users are the ones least like to use rel="accessibility". They didn’t care enough about accessibility to make the site accessible in the first place.

Kazu makes a stirling point that the accessibility of a website speaks for itself. Most accessibility statements I’ve read were simple wrong. So the accessibility information is usually the worst way for disabled people to get information about the accessibility a website!

Comment by Bruce

“I think rel=”accessibility” is a stupid idea”

Heh. Good to see you’ve been working hard on your people skills.

“a problem which doesn’t exist” Do you never hear laments that an accessibility link is hard to find? Those of us with experience of making commercial websites often do.

Also, your second argument has a logical flaw. The fact that many accessibility statements are “simple wrong” (how do you know?) is not an argument for or against any particular method of flagging an accessibility link.

It’s true, I agree, that many accessibility statements are lumps of acronyms that give no help to visitors (but the legal departments like them as they say “we’ve followed WCAG”).

But many others have useful information about PDF, use of target="_blank" amd, crucially, contact information about how to request information in alternative formats. In the real world, this is often the way that accessible information is disseminated; it’s considered to be cheaper to send out ad hoc Word versions of documents than it is to publish them in decent HTML, particularly if the CMS is archaic and doesn’t come close to ATAG conformance.

In commercial organisations, the contact point for that is a different person than the generic contact address, so it’s useful to have this contact address on the accessibility page too.

Comment by Andy Mabbett

“the accessibility information is usually the worst way for disabled people to get information about the accessibility a website”

So you’ll be writing to WAI soon, telling them to remove the section on conformance statements from WCAG2? I’m sure they’ll be grateful for the benefit of your wisdom.

Comment by Henny

I think you may have missed the point here Ben.

Yes you can find an “Accessibility” link by listing links, doing a search and so forth but this solution is proposed to *augment* this (or any) process. In other words it is separate from and can be added to the list of ways to find a link in a page. As pointed out above this is much in the same vein as copyright and so on.

We’re looking for ways to improve the web here rather than just sit back and use what exists now. This is an additional means to solve a problem of users constantly complaining that accessibility links are at the bottom of a page. See Ann McMeekin’s poll “Where on a page do you put your accessibility link” http://answers.polldaddy.com/poll/1483867/ for debate on this.

“The sites most in need of providing alternative services for disabled users are the ones least like to use rel=”accessibility”. They didn’t care enough about accessibility to make the site accessible in the first place.”

Whilst this is true (29% of respondents in Ann’s poll asked what was an accessibility link is after all) it is a mute point within the confines of this discussion. We are discussing if this should be added to HTML5 which is a specification and not a set of educational support documents or even implementation guidelines. Education and outreach is done separately from this by responsible web developers and advocates as indeed Bruce is.

Comment by rel, rev, and HTML5 | Wisdump

[…] For example, the Google-imposed rel=nofollow will be officially added in HTML5, but the seemingly convenient rel=feed may be dropped due to browser implementation. Other interesting link relations mentioned are rel=search, which obviously points to a search page, and rel=sidebar, which refers to a document “shown in a secondary browsing context (if possible), instead of in the current browsing context.” More are being proposed here, including rel=accessiblity. […]

Comment by Ben Millard

Bruce, if the website is accessible then users won’t need to find accessibility information. Kazu hit the nail on the head with that observation.

How do you know “[…] many accessibility statements are lumps of acronyms that give no help to visitors”? Same way I do: you’ve read a lot of them. You’ve talked to many professionals and users who have read even more of them. It’s a well-known phenomena.

There are almost no excuses for using PDFs on websites. And there are no excuses for using target="_blank"! Describing the crummyness of a website’s accessibility in the Accessibility Statement does not excuse it from having crummy accessibility. The “reasonable adjustment” is to fix the crummy aspects of its accessibility.

I’d say a Contact Us page is where all the contact information should be. The clue is in the name! If there are multiple contact points, including an Accessibility Officer, they should all be listed there. (Or linked to on separate pages, if there’s a really huge amount of it.)

Henny, introducing another useless rel value would not be an improvement to the web. Making more websites accessible would be an improvement to the web.

Why would this be useless? Because rel values are rarely exposed to users, so it isn’t how they’d expect to find such a link. But looking for a link with “access” or “accessibility” in its link text is consistent with how users already look for interesting links. Such as “Contact” or “News”. (These words should be translated to other languages on foreign or multilingual sites, obviously.)

Using headings, lists and paragraphs with good alt text for images (and so on) will always be the basis for an accessible website. That isn’t “sitting back”. That’s “doing it properly”. When it’s done properly, the site is usable for everyone without finding and reading an essay about how to use it.

The point is to make accessible websites. rel="accessibility" is what misses the point.

(I hope I got all the typos, this time!)

Comment by Brian Graddon

You say “There are almost no excuses for using PDFs on websites. And there are no excuses for using target=”_blank”!”

Have you ever made a website?

“Almost no excuses”? Here’s one: the boss/ legal department demand that 55 pages of nonsense be on the website *now* and it’s 4pm on a Friday. So the PDF is made from a structured Word document.

The house policy is that external links are opened in a new browser window, and as a content editor, there is no way to get JavaScript added to the site to do it the “right” way.

These are real-world situations that real-world developers face every day. It isn’t perfect, but saying that there are “no excuses” is the cloud-cuckoo land talk of standardistas who’ve never worked on real-world sites.

Comment by steve faulkner

“It isn’t perfect, but saying that there are “no excuses” is the cloud-cuckoo land talk of standardistas who’ve never worked on real-world sites.”

Are you inferring that award winning Calthorpe park school web site [http://calthorpepark.hants.sch.uk/] is not “real-world”? It’s one of the most “successful and modern mixed comprehensive secondary school web sites in Hampshire”

Comment by Jordan Clark

I for one will be using rel=accessibility on the almost-ready redesign of my personal website. It can’t hurt, can it? …and for the sake of an extra 19 bytes (17 if you omit the quotes), it would be mean not to apply it!

Bruce: don’t worry to much about “proving your worth,” as you put it, to the powers-that-be; if enough people use it, it will eventually get standardised anyway (think IMG, EMBED etc.)

And to those who are saying that it is a stupid idea, I ask: got any better ones?

Also, this article has also made me rethink the location of the link to the Accessibility Statement in my redesigned template (which is, predictably, currently in the footer). I’m now thinking about moving it up to the top, maybe directly after the “Skip to Content” link.

Anyway, thanks for the ideas, Bruce!

Comment by Jim O'Donnell

“Why would this be useless? Because rel values are rarely exposed to users, so it isn’t how they’d expect to find such a link.”

Opera exposes @rel values (help, copyright, glossary, author, contents etc.) from the document head in a navigation toolbar. Other browsers may offer an inferior experience but that’s no reason not to promote a useful, yet underused, feature of HTML 4.

Comment by Gary Miller

I’m not up to speed with the technicalities of using link relationships, but surely anything we can do to further promote accessibility is worth doing?

Comment by bruce

Thanks for the support, Jordan; can you let me know when you’ve added it, and the URL please? I’ll compile a list of pages using it.

Jim – thanks for bigging up the Opera navigation toolbar. I deliberately didn’t, so people didn’t think that rel=accessibility was a way to promote my employers, but now you come to mention it, yes – it could be exposed in user agents just like Opera does.

Comment by patrick h. lauke

nice to see that hixie’s people skills have rubbed off on ben as well…it was only a matter of time, i guess. and then people wonder why i don’t frequent accessifyforum any more…

anyway, a firefox extension to expose these sorts of things should be fairly straightforward to make (though of course a native behaviour, not requiring users to install anything, would be preferable). if i get a spare hour sometime, i’ll get on it…

Comment by Christophe Strobbe

I think auto-discovery of such information is a good idea.
What do people think of another variation on this theme: identifying breadcrumb trails? There is no role for breadcrumb trails in the WAI-ARIA last call working draft (presumably because it doesn’t map to existing accessibility APIs such as GNOME ATK, javax.accessibility and IAccessible2) even though it’s a fairly common feature on website. The problem is that it sometimes confuses blind users: for example, a user follows links to a product description and then encounters a breadcrumb trail that starts with “You are here: Home > …”, but “Home” is not the destination he/she had in mind.

Jim O’Donnell wrote: “Opera exposes @rel values (help, copyright, glossary, author, contents etc.) from the document head in a navigation toolbar…”

So does SeaMonkey. It’s a pity that Firefox needs plug-ins for functions that have been available in SeaMonkey for several years.

Ben Millard wrote: “So the accessibility information is usually the worst way for disabled people to get information about the accessibility a website!”

There is more to accessibility information than conformance claims, for example, information on resizing text in a browser (as on the WAI website, the DIAS website in Germany, etcetera.

Comment by Ben Millard

Patrick (and others), I’ve already given several examples of “a native behaviour, not requiring users to install anything” which make an accessibility link perfectly discoverable. Simply use the word “accessibility” in the link and it is trivial for users to find via common techniques they already use:

1. Normal skim-reading.
2. List of links.
3. Find-in-page.
4. Voice activation.

Indeed, doing this makes rel="accessibility" redundant on the Big City Plan website. And it duplicates the link relationship, just to increase the irony! :D

Navigation toolbars are present in Opera and Lynx. I use the Link Widgets Add-on for Firefox, too. But websites rarely provide relation metadata, so they rarely “light up”. Only Lynx shows it by default and it just gets in the way. Especially on sites with 50+ <link rel> elements.

As such, special rel-sensitive navigation bars are rarely how users find links.

Another factor I recently realised: the accessibility information page will be just as inaccessible as all the other pages. So even if it carries useful workarounds to current shortcomings of a website, users will struggle to read them due to those shortcomings!

If the website is accessible, there’s no need for users to read an essay before they can understand it in the first place. At best, rel="accessibility" formalises a way for bad websites to link to a page of excuses.

So far, my original sentiment has stood up to scrutiny: rel="accessibility" is a stupid idea which misses the point of accessibility.

(Incidentally, Ian Hickson has been amazingly and consistently diplomatic with feedback on HTML5. Especially considering the barrage of nonsense and bitching he’s had to read since the WHATWG effort joined W3C.)

Comment by Christophe Strobbe

Ben Millard wrote: “… the accessibility information page will be just as inaccessible as all the other pages. So even if it carries useful workarounds to current shortcomings of a website, users will struggle to read them due to those shortcomings!”

With that kind of reasoning, we can all stop writing accessibility guidelines and techniques.
Ben, accessibility is not black and white, and the accessibility of the web content is not the only component that determines accessibility. I recommend that you go and read Essential Components of Web Accessibility before this becomes yet another discussion between HTML5 guys and accessibility practitioners in which the HTML5 guys pretend that they know accessibility better than the accessibility practitioners. We’ve had enough of those on the WAI-XTech mailing list.

Comment by David Sloan

I seem to write this a lot in relation to discussions on accessibility information… :)

Not everyone who needs accessibility information knows they are disabled. So an ‘accessibility’ hyperlink is of limited use to someone who doesn’t know what ‘accessibility’ means (let alone something like find-in-page).

Yet, providing information on how to make a web site easier to use is in my view definitely worthwhile. For someone whose eyesight or dexterity is declining (for example due to the ageing process), this information may be the difference between them independently discovering how to make an adjustment using their browser to compensate for their impairment, and giving up using the Web because they can’t read the text anymore.

If rel=accessibility solution can help people discover this information, then great. The challenge remains in the implementation – exposing the information to the people who need it – not just people who know they need accessibility information, but people who don’t.

If browsers can generate a big ‘Help!’ toolbar button from rel=accessibility, that might just be the solution we need – though then we have to implement the solution, and make it available to the people who need it. That’s a whole different problem, as I’d be fairly confident that most won’t have heard of Opera or any extension which generates links or buttons from rel values…

Comment by Arielle Cruz

Hello. I’m coming from the Philippine Web Accessibility Group mailing list; somebody provided a link to this article, the comments to which I find very interesting.

@David Sloan:

“Not everyone who needs accessibility information knows they are disabled. So an ‘accessibility’ hyperlink is of limited use to someone who doesn’t know what ‘accessibility’ means…”

An “accessibility button” provided by a User-Agent might be of the same value for the very people you described.

With that, I will have to state my agreement with Ben Millard, especially when he said, “if the website is accessible, there’s no need for users to read an essay before they can understand it in the first place.”

The only prose that a casual Internet user, disabled or not, needs to read– apart from “real” site contents– is the User-Agent’s/Accessibility Software’s user manual.

Cheers! =)

Comment by Ciaran McNulty

I don’t think using the word ‘accessibility’ inside a hyperlink is a good enough solution.

In this day and age it’s worth considering that the whole world isn’t Anglophonic.

Comment by Isofarro

@Arielle says: “With that, I will have to state my agreement with Ben Millard, especially when he said, “if the website is accessible, there’s no need for users to read an essay before they can understand it in the first place.””

No. This treats accessibility as a problem that has to be solved, a burden we have to bear. Content that is perceivable isn’t enough for accessibility. Content needs to be operable, understandable and robust. Many times, when dealing with rich media and/or rich interaction – something Ben Millard has repeatedly admitted he has zero experience with – means having to go beyond the text of WCAG. That means bringing in new techniques that go well beyond just removing barriers, but techniques that vastly improve the user experience for people with disabilities.

Relying on serendipity for these features to be used is just a waste of an opportunity. An accessibility statement is a decent place to highlight features that accommodate a disabled person far far more than just your average trawler.

Ideally, an accessibility statement is not needed, but building websites for practical use on the web and by real people, an accessibility statement is a catch-all for highlighting improvements that directly benefit a disabled person that may on the face of it not be obvious.

Comment by Arielle Cruz

@Isofarro

“This treats accessibility as a problem that has to be solved, a burden we have to bear.” Yes, accessibility is a problem that has to be solved. But is this (what we’re talking about) a good or even necessary step in solving this problem?

I will also ask who “we” are referring to, because:

a. if it refers only to designers or frontend developers, then I would say that it’s unfair that we alone get to carry this burden;

b. if it refers to both the latter and User-Agent developers, then accessibility becomes a merely a problem of proper implementation of existing specs– specs that are already robust to begin with;

c. if it refers to all stakeholders, including content creators/developers and end-users, then we are at an ideal situation where “an accessibility statement is not needed”.

“Content needs to be operable, understandable and robust. Many times, dealing with rich media and/or rich interaction… means having to go beyond the text of WCAG.”

I agree. But I also believe that with the stated needs, a web designer’s responsibility ends with making content operable. Considering the first IF, it is not up to us to make content understandable and robust, whether such content is rich or not. That is up to content creators and developers. Perhaps we should be responsible for orienting the content creators whom we work with about accessibility, but after that, there is only little that can still do.

“An accessibility statement is a decent place to highlight features that accommodate a disabled person far far more than just your average trawler.”

True, it is a decent place to highlight features. _Highlight_ features.

I think the best features that an end-user has to know are those that are offered by the software that s/he using; because no amount of HTML/CSS/JS hacking will ever beat those. Besides, “accessibility” is not just for persons with _disabilities_ (i.e.: paralytics, blind or deaf people). A 150/150-vision person needs “accessibility features”; so does a no-money-for-a-new-mouse dude who lives between two mountains in some third-world country (ahem!). But before I digress too much, the point is (and to paraphrase David Sloan):

Not everyone who needs accessibility information is disabled. So an “accessibility” hyperlink is of limited use to someone who thinks he doesn’t need accessibility information.

Cheers! =)

Comment by David Sloan

@arielle “The only prose that a casual Internet user, disabled or not, needs to read– apart from “real” site contents– is the User-Agent’s/Accessibility Software’s user manual.”

This is rather idealistic and optimistic to say the least!

@arielle “and to paraphrase David Sloan): Not everyone who needs accessibility information is disabled. So an “accessibility” hyperlink is of limited use to someone who thinks he doesn’t need accessibility information.”

Yes. But to remind you, I said “not everyone who needs accessibility information *knows they’re disabled*” (and I should have added to that “disabled – in the eyes of a web site developer”).

To say in reply “RTFM!” (and I paraphrase @arielle here) seems to me to fail to understand the adventitious nature of disability present in a majority of people (especially obvious in older web users), along with the low levels of technical willingness that mean many people may be more likely to give up than try to solve the problem.

If Bruce’s solution gives browser developers an easy way to provide an obvious ‘Site Help’ browser toolbar button (not labelled ‘accessibility’), which takes a user to some useful advice about helping them with their accessibility issues in the current site and more generally on the web, then we may just help a few more people carry on as surfers. So I’m all for it.

Comment by Arielle Cruz

@David

“This is rather idealistic and optimistic to say the least!”

It truly is idealistic, and optimism is a fault that I am glad to have. =)

And yes, I have intentionally mangled your statement for it to reflect my own point, which yours missed only by a hair: accessibility is not just for people who have disabilities and many people– like, as you say, “older web users”– don’t know accessibility is for them too.

“If Bruce’s solution gives browser developers an easy way to provide an obvious ‘Site Help’ browser toolbar button (not labelled ‘accessibility’), which takes a user to some useful advice…”

So now, the disabled/handicapped/technologically-challenged person is expected NOT ONLY TO KNOW how this solution is implemented (i.e. where to find “the button” and to actually know what it does), BUT ALSO TO LEARN specific modes of operation for individual sites that may or may not be in common with other sites?

That’s not just “RTFM”, it’s “RTFM! RTFM! …then forget the second one because you won’t be using it for the next site… now, RTFM again!”

I’m not against putting some site help/description document, don’t get me wrong. But this rel=accessibility solution and the implementation that you, for one, propose is a bit more idealistic and optimistic about end-user abilities than I allow myself to be. =)

Comment by David Sloan

@arielle, based on your response, I feel I need to make a few clarifications of my approach:

1. The accessibility page should include or link to (via an authoritative resource like the BBC’s My Web My Way) generic information helping someone make accessibility adjustments (like text resizing) that hold as far as possible across the Web. There may also be site specific information, but this shouldn’t be contradictory to the point that it causes confusion in the way you describe.

2. The toolbar button (or other solution generated by the user agent to allow access to the page referenced by rel=accessibility) should be clearly labelled such that a non-techy user would most likely notice it and be encouraged to click it. I agree with you that this is by no means an easy task to complete, but we are talking about something more conspicuous than an ‘accessibility’ link in the page footer. The whole aim is to make it simple, and easy to find and use, not the cognitive challenge you describe. Don’t you think that’s worth investigating?

@arielle, so far your responses have been to reject the solution proposed by Bruce, and my support for it, without offering any alternative. What would you suggest instead, beyond your optimism that users needing accessibility advice will somehow discover it by reading the user agent’s manual?

I do accessibility research, so if you have a better idea, I’m genuinely interested in exploring it!

Comment by Arielle Cruz

@David

Thank you for your clarifications.

“The accessibility page should include or link to (via an authoritative resource like the BBC’s My Web My Way) generic information helping someone make accessibility adjustments (like text resizing) that hold as far as possible across the Web.”

Browser-specific instructions on text resizing, disabling style sheets or specific style elements, disabling scripts and plug-ins, etc. can be had by pressing F1 or going to the Help menu. While it maybe true that most end-users don’t press F1 for anything these days, how can we expect them to know that clicking something like a “wheelchair icon” button or doing a combo like CTRL-SHIFT-A will give them information that they might need– especially when considering, and I quote you properly this time, that “[n]ot everyone who needs accessibility information knows they are disabled…”?

To be fair, the BBC initiative that you mention is great. The content is certainly better composed than the Firefox and Opera help pages. But– and here begins that idea that you ask of me–, imagine having the My Web My Way’s content quality in browser help files. Browsers already have the F1 shortcut, browsers already have the Help menu; really, is there still a need for making a new button and a new shortcut for accessing essentially the same content?

Apart from that necessary content improvement, the only problem that I’m seeing now is getting people to use the F1 key or the Help menu. Yes that is not a simple problem, but making new browser functions that essentially do the same things as old ones does not eliminate the problem of getting people to use such functions.

Aside: the Opera Accessibility Statement page actually links to My Web My Way. Just press F1 > Support & Tutorials. =)

Comment by Ben Millard

Arielle Cruz, thank you. I am comforted to see web accessibility has an equally sane (but far sweeter!) voice on your side of the world.

Ciaran McNulty, I guess you missed the part where I said “These words should be translated to other languages on foreign or multilingual sites, obviously.” A couple of the other rebuttals to my criticisms of rel="accessibility" are due to similar oversights.

Comment by Ciaran McNulty

Ben,

Surely having the phrase translated in each instance completely blows away any chance of autodiscovery, unless a user-agent is expected to keep a dictionary of all possible terms?

Comment by Ben Millard

There is no need for “auto”-discovery of these or any other links. Well-written link text makes relevant links easy to find.

Using the word for “accessibility” makes the link trivial to discover by several normal methods. (I’ve already listed listed what these are.)

Comment by Russell Parrott

Bruce, read this with interest, personally I love the idea. and I see a number of implementations already. The other thing though is it may be a way of getting the search engines to consider accessibility (though doubtful?) in their alogorthims. Now that would be great me thinks.

Russell Parrott
http://parotdesign.wordpress.com/