Accessibility, Web Standards, and Authoring Tools

by Christopher Schmitt

18 Reader Comments

Back to the Article
  1. A question for the group – I can make most form elements keyboard accessible through the use of the accesskey attribute of the <label> tag but doing so sometimes overrides the accesskeys for browser menus. Is this ok?

    here’s some code to try out. note how alt-f is taken over by the page and no longer pops the file menu…

    <form>
    <fieldset>
    <input type=“radio” id=“r” name=“r” /><label for=“r” accesskey=“r”>Radio button</label>
    <input type=“radio” id=“f” name=“r” /><label for=“f” accesskey=“f”>Radio button</label>
    </fieldset>
    </form>

    Copy & paste the code below to embed this comment.
  2. When using Accesskey it is advisable to avoid using any of the letters used by the browser i.e. F, E, V, A, T & H (I’m sure I have seen this information as a Web Standard some where…). As these functions are preset and may be required by the user and by over riding them you may disorientate and confuse the user, which is not a good thing. See http://www.seemug.org.uk for accesskey in action. Just my 2 cents :)

    Copy & paste the code below to embed this comment.
  3. A-Prompt (http://aprompt.snow.utoronto.ca/) is a simple and easy to use software program designed to aid web developers and content authors create sites that are accessible to the widest possible audience. Based on the WAI guidelines, this software toolkit is made available through the collaborative efforts of the University of Toronto’s Adaptive Technology Resource Centre(http://www.utoronto.ca//atrc/) and the Trace Center at the University of Wisconsin(http://trace.wisc.edu/).

    Ausi disponsible en français(http://aprompt.snow.utoronto.ca/french/).

    Copy & paste the code below to embed this comment.
  4. I apologize for posting a little off of the topic (not sure where else to ask this question), but I’ve recently been working on building/designing my personal site according to XHTML and CSS standards. So far, nearly everything has gone smoothly and I’ve learned tons about standards while having lots of fun. However, I have encountered one small problem: a part of the layout in my portfolio section breaks when viewed with Internet Explorer 5 for the macintosh. I’ve tested the site in IE5/NS6/Mozilla/Opera on a PC (the design is hidden from older browsers) and IE5/NS6/Mozilla on a Macintosh, and it appears that IE5 for Macintosh is the only browser in which this particular bug occurs. I’m not sure what’s going on, although I’m sure that my code is an ugly hack anyway.

    Here’s the actual page:
    http://www.digital-hearth.com/portfolio/web.html

    Here’s a page with screenshots (.gif) of both the correct version, the buggy version, and the css and html which controls the presentation:
    http://www.digital-hearth.com/portfolio/incorrect.html

    Here’s a link to my main style sheet:
    http://www.digital-hearth.com/style/mainstyle.css

    If anybody has any suggestions or tips on how to hack through this little bug (although it might not be a bug, could just be my crappy code), they would be utterly appreciated. Failing that, if there is somewhere else that I should be asking this question, perhaps you could point me in the right direction? Thanks again.

    Copy & paste the code below to embed this comment.
  5. I don’t know if I quite agree with Ben (http://www.alistapart.com/stories/tools/discuss/#ala-10).

    I think it depends on which groups of users is using page building tools that are designed to output accessible HTML. The neophytes will notice nothing as they author pages in these new tools. They’ll fill in the prompts and dialogs assuming that pages have always been built this way.

    I think the real group users to worry about are the supposedly-informed, supposedly-technically-proficient users. These are the ones that will complain the most about the new authoring tools because they’ll have all the bad habits gained from previous generations of tools. They’ll also be attached to a set of server scripts that parse and generate poorly-formed markup. They’ll be hesitant to adapt to these new tools because they will require throwing out a lot of code they spent money on.

    I’ve been designing accessible, standards compliant sites since ‘97 and one of the things I’ve noticed is that a lot of open source server scripts (blogs, bulletin boards, CMS, etc.) generate bad, and inaccessible markup. I fact a lot of my work these days is simply correcting scripts someone else wrote so that it generates accessible markup. Perhaps there should be a compaign among programmers of server-side code to make certain their scripts generate accessible markup. In theory, these scripts, especially the content management ones, fall under the Authoring Tool guidelines of the WAI.

    Copy & paste the code below to embed this comment.
  6. This is not directly related to Christopher Schmitt’s article but it is about accessibility and I didn’t know where else to put it*.

    I don’t know if anyone else has noticed this but Mozilla and IE seem to implement ACCESSKEY differently.

    Mozilla gets it right: Invoking the keystroke associated with a page element immediately activates that element. IE 4 for Windows used to do it the correct way but further iterations have inserted the unnecessary step of hitting ENTER to invoke the element.

    However my complaint (And yes, I filled a bug with Mozilla many months ago: http://bugzilla.mozilla.org/show_bug.cgi?id=93039 .), is not directly related to that. To understand my complaint consider the following markup:

    ==
    Jump to [url=”#anchorname“accesskey=“n” ]site

    navigation[/url]

    [Much intervening markup and content]

    <a name=“anchorname”>Navigation Links</a>

    [More navigation links that follow.]
    ==

    IE and Mozilla handle this markup differently. If the user invokes the accesskey in IE (For windows at least.) , the system focus is shifted to the anchor and link tabbing proceeds immediately to any link that follows that anchor, thus allowing the user to hop back and forth in a page and quickly bypass links, arguably the intent of ACCESSKEY.

    Mozilla, while getting nearly everything else right, doesn’t do this. If the accesskey is invoked, the page shifts to the anchor but the system focus is not also shift. If the user attempts to tab, the links still take focus in the order they appear in the markup. To me this defeats the point of accesskey: to offer users a shortcut to content or navigation links that can be used at any time.

    I guess this is old news. The W3C recs don’t explicitly state what the correct behavior on this point should be and Mozilla One (And all browsers derived from it.) will soon be unleashed on the world but, I still think this is an accessibility issue that needs to be clarified. Which behavior is better for accessibility?

    • I miss the thread sorted topics of the ALA’s old BBS! However I am very happy to have the boards back in any form!
    Copy & paste the code below to embed this comment.
  7. I recently reviewed the video “ENABLE: People with Disabilities and Computers” and found it to be an excellent resource for healthcare professionals, special educators, and persons with disabilities. Here is an excerpt of the review of “Enable”.

    = VIDEO REVIEW =

    For many people with disabilities, assistive technology can be vital for their independence, quality of life and effort to become integrated into society. In the award-winning video “ENABLE: People with Disabilities and Computers”, you will meet a deaf-blind university student, a business man paralyzed from the neck down, a speech impaired person, and many other people with disabilities who demonstrate how technology assists them in achieving their objectives and life goals, and allows them to fully participate in society.

    Educators, disability professionals, caregivers, employers, and others will be able to use this video in a variety of settings, from training faculty, students and work site supervisors, to helping persons with disabilities understand how technology can assist them.

    The “Enable” video offers numerous profiles of individuals with disabilities who have experienced how technology can enhance their lives. The profiles cover a range of disabilities, including blindness, speech, hearing and mobility impairments of various kinds, stroke, and cerebral palsy.

    Each of the individuals profiled describes his or her disability in a personal, unique way, often emphasizing the liberating impact of technology in all aspects of their lives, at work, at school and at home. This video shows all kinds of adaptive technology, both hardware and software.

    If you are interested in receiving a copy of the video “ENABLE: People with Disabilities and Computers” or would like more information, go to http://www.rehabtool.com/video

    (This 45-minute video produced by David Bolnick, Ph.D. et al. is closed-captioned and includes narrative descriptions for the visually impaired)

    D. Gerard, Editor
    RehabTool.com

    Copy & paste the code below to embed this comment.
  8. >Lastly comes Bobby… (www.cast.org/bobby)
    Bobby provides one of the most counter intiutive
    interfaces I met so far.

    Marek

    Copy & paste the code below to embed this comment.