Access Keys/Schl�ssel/llaves/clefs/chiavi
I’m an avid reader of other blogs related to CSS/HTML/etc. Many of these discuss web standards and accessibility in one form or another. One of the original blogs that got me interested in many others is authored by Dave Shea on his website, www.mezzoblue.com (also linked on the right).
The discussion to which I’m most particularly attached to right now is the use of Access Keys in a browser. Dave Shea had an excellent set of comments about not using them. However, after reviewing several articles about why they aren’t very consistently implemented and what authors would like to see, I find that one of the facets lacking in this discussion is that of Internationalization (I18N). After all, Derek Featherstone even has a few suggestions on what he would like to see, but seems to ignore this factor.
Derek’s example (mentioned in the link above) includes the following statement:
I would love for the ability to always make Ctrl + Shift + H take me to the home page of the site I am on, Ctrl + Shift + S to take me to search for that site, and for Ctrl + Shift + C to take me to the contact page/form.
Consider if you will, the user having to then browse a site that was written in Spanish. Should the user choose to define the home page with the Ctrl+Shift+C for “Casa”, then the attempt to view the contact page fails. If the browser itself should rearrange the set of keys so that they best fit for Spanish (i.e., Ctrl+Shift+C takes you to the home (casa) page, and so on), then there needs to only be a means of semantically defining pages and links within a website. This may require the use of a site map standard with specific locations defined using properties that are consistent across language barriers.
For example, suppose the site map has a list of links. You might define the links as follows:
- <a href=”home.html” linktype=”home”>Home</a>
- <a href=”contact.html” linktype=”contact”>Contact</a>
- <a href=”search.html” linktype=”search”>Search</a>
This would require that the page that contains this new “site map” for browser navigation be in a consistent naming/location so that the browser doesn’t have to spider a site to locate this file.
What is really going on here is the growing need or concept of a browser being aware of the “3-dimensional” nature of a website and how a site map actually provides a means of allowing the browser to become aware of the navigation beyond the standard page links.
Time to throw in a few monkey wrenchs. The use of a single site map may not be the best solution. After all, many sites have sections inaccessible to users without the proper security. A browser does not need to be aware of what is beyond the secure areas until after the user gains authorized access to those areas. Does this mean providing folder level site maps? Or should there be multiple site maps accessed based upon security?
Ah, much to consider for the future.
