<?xml version="1.0" encoding="utf-8" ?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
	<title>Web Design&gt;Accessibility</title>	<link>http://tc.eserver.org/dir/Web-Design/Accessibility</link>
	<description>A listing of the most recently indexed works about Web Design and Accessibility in the field of technical communication.</description>
	<language>en-us</language>
	<copyright>Copyright (c) 2005-08 by the EServer. All rights reserved.</copyright>
	<managingEditor>tclib-editorial@eserver.org (TC Library Editorial Board)</managingEditor>
	<webMaster>webmaster@eserver.org (Geoffrey Sauer)</webMaster>
	<image>
		<url>http://tc.eserver.org/images/newlogo.gif</url>
		<title>Web Design&gt;Accessibility</title>
		<link>http://tc.eserver.org/dir/Web-Design/Accessibility</link>
	</image>
	<item>
		<title>HTML 5 and Accessibility</title>
		<link>http://tc.eserver.org/35388.html</link>
		<guid>http://tc.eserver.org/35388.html</guid>
		<description>Probably the most worrying thing about the HTML Working Group is the lack of respect for differing opinions that some working group members have. The apparent disinterest in accessibility is another troublesome factor.</description>
	</item>
	<item>
		<title>HTML 5, Microformats and Testing Accessibility</title>
		<link>http://tc.eserver.org/35389.html</link>
		<guid>http://tc.eserver.org/35389.html</guid>
		<description>Testing is vital, particularly at the border of accessibility theory and practice. I wonder, for example, if tabindex and accesskey would have made it to the HTML4 spec if there had been full testing with assistive technology users? What I really want to know from the HTML5 people is who they think is going to do this research that will provide the evidence that their gang requires before useful attributes are restored to the specification.</description>
	</item>
	<item>
		<title>HTML 5 and the Summary Attribute</title>
		<link>http://tc.eserver.org/35392.html</link>
		<guid>http://tc.eserver.org/35392.html</guid>
		<description>As I wrote in Help screen reader users by giving data tables a summary, the summary attribute on the table element can be used to provide information that helps non-sighted users understand data tables. The current draft of HTML 5 requires that validators display a warning if they encounter a summary attribute, since it is now an &apos;obsolete but conforming feature.&apos;</description>
	</item>
	<item>
		<title>Keyboard Accessibility: Basic Steps Towards a More Usable and Accessible Site</title>
		<link>http://tc.eserver.org/35396.html</link>
		<guid>http://tc.eserver.org/35396.html</guid>
		<description>A presentation which shows examples of best-practices in web design for accessibility to users who interact with sites exclusively through the keyboard.</description>
	</item>
	<item>
		<title>Creating Accessible Tabular Data Tables: A Help Authoring Guide</title>
		<link>http://tc.eserver.org/35188.html</link>
		<guid>http://tc.eserver.org/35188.html</guid>
		<description>This Fast Track tutorial demonstrates and employs web standards and accessibility methods for tabular data table creation. It is presented free of charge to the community as a help authoring, technical writing and web design guide.</description>
	</item>
	<item>
		<title>Ten Ways To Make Your XHTML Site Accessible Using Web Standards</title>
		<link>http://tc.eserver.org/35152.html</link>
		<guid>http://tc.eserver.org/35152.html</guid>
		<description>Let’s take a look at 10 ways to improve the accessibility of your XHTML website by making it standards-compliant. We’ll go the extra mile and include criteria that fall beyond the standards set by the W3C but which you should follow to make your website more accessible. Each section lists the criteria you need to meet, explains why you need to meet them and gives examples of what you should and shouldn’t do.</description>
	</item>
	<item>
		<title>Designing for &quot;Mature&quot; Users</title>
		<link>http://tc.eserver.org/34936.html</link>
		<guid>http://tc.eserver.org/34936.html</guid>
		<description>According to a study by the Annenberg School at USC, American Internet users include: 75% of adults aged 56-65 and 41% of adults over 66. If we want to design for the bulk of our users, we had best consider the more mature user groups.</description>
	</item>
	<item>
		<title>From Web Accessibility to Web Adaptability</title>
		<link>http://tc.eserver.org/34781.html</link>
		<guid>http://tc.eserver.org/34781.html</guid>
		<description>This article asserts that current approaches to enhance the accessibility of Web resources fail to provide a solid foundation for the development of a robust and future-proofed framework. In particular, they fail to take advantage of new technologies and technological practices. The article introduces a framework for Web adaptability, which encourages the development of Web-based services that can be resilient to the diversity of uses of such services, the target audience, available resources, technical innovations, organisational policies and relevant definitions of &apos;accessibility&apos;. Method The article refers to a series of author-focussed approaches to accessibility through which the authors and others have struggled to find ways to promote accessibility for people with disabilities. These approaches depend upon the resource author&apos;s determination of the anticipated users&apos; needs and their provision.</description>
	</item>
	<item>
		<title>Web Design For Dyslexia</title>
		<link>http://tc.eserver.org/34773.html</link>
		<guid>http://tc.eserver.org/34773.html</guid>
		<description>People with dyslexia frequently experience discomfort when reading because they find it more difficult to ‘decode’ the words on the page, and can also find it difficult to remain focussed on a particular piece of text. Some people may also have to concentrate more to remember what they have already read, which means they will tire more easily.</description>
	</item>
	<item>
		<title>Designing for Screen Reader Compatibility</title>
		<link>http://tc.eserver.org/34634.html</link>
		<guid>http://tc.eserver.org/34634.html</guid>
		<description>Techniques that work for one screen reader almost always work in other screen readers. In some cases, one of the screen readers has capabilities that the others do not have, or handles some types of content better than the other screen readers. Still, developers are almost always better off when they focus on accessibility standards and generally-accepted accessibility techniques than when they focus on screen reader differences.</description>
	</item>
	<item>
		<title>Adopting WCAG 2</title>
		<link>http://tc.eserver.org/34642.html</link>
		<guid>http://tc.eserver.org/34642.html</guid>
		<description>It is six months since the release of WCAG 2.0 and I thought it might be interesting to see how extensively it has been adopted as a bench mark for determining web content accessibility. Over this time, I have felt that the rate of adoption has been relatively slow and the number of countries and other regulatory authorities now using WCAG 2 is lower than I expected.</description>
	</item>
	<item>
		<title>Common Look and Feel Standards for the Internet, Part 2: Standard on the Accessibility, Interoperability and Usability of Web Sites</title>
		<link>http://tc.eserver.org/34643.html</link>
		<guid>http://tc.eserver.org/34643.html</guid>
		<description>This standard is directed toward ensuring equitable access to all content on Government of Canada Web sites.</description>
	</item>
	<item>
		<title>Web Axe: Practical Web Design Accessibility Tips</title>
		<link>http://tc.eserver.org/34615.html</link>
		<guid>http://tc.eserver.org/34615.html</guid>
		<description>A podcast and blog featuring practical web design accessibility tips.</description>
	</item>
	<item>
		<title>New Accessibility Guidelines A &quot;Welcomed Update&quot;</title>
		<link>http://tc.eserver.org/34616.html</link>
		<guid>http://tc.eserver.org/34616.html</guid>
		<description>The World Wide Web Consortium recently approved new accessibility guidelines. Passed in December 2008, the new &quot;Web Content Accessibility Guidelines 2.0&quot; is now the official recommendation for web accessibility for the disabled. This new WCAG 2.0 document, a welcomed update, replaces the WCAG 1.0 W3C recommendation of 1999. This article is part one in a series discussing the impact of WCAG 2.0 on your website.</description>
	</item>
	<item>
		<title>New Accessibility Guidelines Part II: Operability</title>
		<link>http://tc.eserver.org/34617.html</link>
		<guid>http://tc.eserver.org/34617.html</guid>
		<description>The concept behind website operability is simple: Can everybody use the tools and mechanisms required to operate your website? Operability may seem easy, but it can be very challenging. Every control, every link, and every button on your site is a potential point of failure for operability. Without appropriate consideration for the disabled, you run the risk that disabled users will be unable to access your site.</description>
	</item>
	<item>
		<title>New Accessibility Guidelines Part III: Understandability</title>
		<link>http://tc.eserver.org/34618.html</link>
		<guid>http://tc.eserver.org/34618.html</guid>
		<description>The understandability of text is crucial to web accessibility. At broad levels, this means specifying text languages, explaining the meanings of jargon or idioms, and expanding abbreviations to clarify text. It&apos;s not just text that can present a barrier to accessibility, however. A lack of organizational predictability or proper error management can greatly decrease the accessibility of any website.</description>
	</item>
	<item>
		<title>New Accessibility Guidelines Part IV: Robustness</title>
		<link>http://tc.eserver.org/34619.html</link>
		<guid>http://tc.eserver.org/34619.html</guid>
		<description>The fourth principle of the Web Content Accessibility Guidelines requires new web documents to be “robust.” Robustness, future-proofing, user-agent independence, accessibility-supported: All are terms that suggest the same basic idea that your documents should follow standard, supported models for web document types. In many ways, this is the simplest and most testable requirement of the WCAG, but the details can be quite complicated.</description>
	</item>
	<item>
		<title>Search Engine Optimization Through Accessibility: How Designing Accessible Websites Leads to Automatic SEO</title>
		<link>http://tc.eserver.org/34504.html</link>
		<guid>http://tc.eserver.org/34504.html</guid>
		<description>This presentation describes how creating an accessible website takes care of its (organic) search engine optimization to a very appreciable extent taking reference from the WCAG 2.0 working draft and the Google webmaster guidelines.This presentation was created and presented by Abhay Rautela to the Sapient creative community at the New Delhi office in February 2007.</description>
	</item>
	<item>
		<title>Back To Basics: How Poor Usability Effects Accessibility</title>
		<link>http://tc.eserver.org/34463.html</link>
		<guid>http://tc.eserver.org/34463.html</guid>
		<description>In recent user testing with a range of participants including Visually Impaired (VIP) and Blind users we found that the majority of problems were common across all groups. However the effect of poor usability is more severe for users with visual disabilities. Surprisingly all of the issues are very familiar and are easy to fix so we thought we’d revisit some of the basics of accessible web design.</description>
	</item>
	<item>
		<title>Effective Alt Text</title>
		<link>http://tc.eserver.org/34473.html</link>
		<guid>http://tc.eserver.org/34473.html</guid>
		<description>It is perfectly possible to diligently apply alt text to every image on a site and create a result that is completely useless. Unless the alt text effectively conveys the information the image displays, it will be ineffective.</description>
	</item>
	<item>
		<title>Pitfalls of Web Accessibility Evaluation Tools</title>
		<link>http://tc.eserver.org/34256.html</link>
		<guid>http://tc.eserver.org/34256.html</guid>
		<description>Automated web accessibility evaluation tools are hard to trust, understand and only provides feedback on a small amount of factors that influence accessibility. Also, a unified web evaluation methodology should be adopted to provide consistent results across tools.</description>
	</item>
	<item>
		<title>Deque Worldspace</title>
		<link>http://tc.eserver.org/34258.html</link>
		<guid>http://tc.eserver.org/34258.html</guid>
		<description>Worldspace is an accessibility analysis tool designed to identify errors with Section 508, and the Web Content Accessibility Guidelines.</description>
	</item>
	<item>
		<title>CAPTCHAs, CAPTCHAs Everywhere</title>
		<link>http://tc.eserver.org/34147.html</link>
		<guid>http://tc.eserver.org/34147.html</guid>
		<description>My business and passion is accessibility and there is obviously a huge problem with these visual CAPTCHAs. If you used alt-text on this image, alt=&quot;e3TJ6Jdp&quot;, that would be fine and very welcome for blind visitors. It would also be welcome for any computer system seeking to sign up for lots of emails. Using alt-text on the image does not solve the problem! The visual image CAPTCHA is fundamentally inaccessible. For the example above, this means very simply that Yahoo excludes people who are blind (or vision impaired) from signing up for Yahoo email accounts.</description>
	</item>
	<item>
		<title>Evaluating Existing Audio CAPTCHAs and an Interface  Optimized for Non-Visual Use</title>
		<link>http://tc.eserver.org/34148.html</link>
		<guid>http://tc.eserver.org/34148.html</guid>
		<description>Audio CAPTCHAs were introduced as an accessible alternative for those unable to use the more common visual CAPTCHAs, but anecdotal accounts have suggested that they may be more difficult to solve. This paper demonstrates in a large study of more than 150 participants that existing audio CAPTCHAs are clearly more difficult and time-consuming to complete as compared to visual CAPTCHAs for both blind and sighted users. In order to address this concern, we developed and evaluated a new interface for solving CAPTCHAs optimized for non-visual use that can be added in-place to existing audio CAPTCHAs. In a subsequent study, the optimized interface increased the success rate of blind participants by 59% on audio CAPTCHAs, illustrating a broadly applicable principle of accessible design: the most usable audio interfaces are often not direct translations of existing visual interfaces.</description>
	</item>
	<item>
		<title>Accessible HTML/XHTML Forms</title>
		<link>http://tc.eserver.org/34001.html</link>
		<guid>http://tc.eserver.org/34001.html</guid>
		<description>Forms are often the most tricky aspect of web development for beginners to get their head around, largely because it means stepping out of the comfort zone of one-way information - no longer are you simply presenting information at the person viewing your site, now you are asking for input, for feedback that you have to process in some way. And just as it may be difficult for HTML beginners to understand just how they handle form data, so is it difficult to understand some of the issues relating to accessibility.</description>
	</item>
	<item>
		<title>Current Browsers and the User Agent Accessibility Guidelines 1.0</title>
		<link>http://tc.eserver.org/34003.html</link>
		<guid>http://tc.eserver.org/34003.html</guid>
		<description>Any effort on the part of web authors to add accessibility features is rendered useless if browsers and assistive technologies don’t take advantage of them. User agent developers need to ensure that their products support these features and, most crucially, make them available to users in an accessible and obvious manner. What follows is a quick run-down of most of UAAG’s guidelines and checkpoints, annotated with comments, suggestions, personal gripes about current levels of implementation, and wishlists for future browser versions.</description>
	</item>
	<item>
		<title>Usable Accessibility: Making Web Sites Work Well for People with Disabilities</title>
		<link>http://tc.eserver.org/33953.html</link>
		<guid>http://tc.eserver.org/33953.html</guid>
		<description>When people talk about both usability and accessibility, it is often to point out how they differ. Accessibility often gets pigeon-holed as simply making sure there are no barriers to access for screen readers or other assistive technology, without regard to usability, while usability usually targets everyone who uses a site or product, without considering people who have disabilities. In fact, the concept of usability often seems to exclude people with disabilities, as though just access is all they are entitled to. What about creating a good user experience for people with disabilities—going beyond making a Web site merely accessible to make it truly usable for them?</description>
	</item>
	<item>
		<title>AJAX Aids Accessibility?</title>
		<link>http://tc.eserver.org/33853.html</link>
		<guid>http://tc.eserver.org/33853.html</guid>
		<description>Yes, if you do it right, using Ajax techniques can improve accessibility. Surprised? You shouldn’t be. Ajax is like most techniques and technologies on the web—they are what you make of them.</description>
	</item>
	<item>
		<title>WCAG 2.0 Checklist</title>
		<link>http://tc.eserver.org/33685.html</link>
		<guid>http://tc.eserver.org/33685.html</guid>
		<description>A simple checklist that presents the principles and techniques of WCAG 2.0 in a user-friendly, understandable format. The language has been significantly changed and simplified from the official WCAG 2.0 specification to make it more easily tested and verified for web pages.</description>
	</item>
	<item>
		<title>Are Accessibility Statements Useful?</title>
		<link>http://tc.eserver.org/33664.html</link>
		<guid>http://tc.eserver.org/33664.html</guid>
		<description>An accessibility statement provides website visitors with information on how to utilize any accessibility features implemented, together with known barriers and how to overcome them. This information is usually presented on a dedicated page within the website. This article will look at the benefits of providing an accessibility statement together with common problems, before evaluating whether accessibility statements are useful.</description>
	</item>
	<item>
		<title>New Accessibility Features in Internet Explorer 8</title>
		<link>http://tc.eserver.org/33548.html</link>
		<guid>http://tc.eserver.org/33548.html</guid>
		<description>Hi, my name is JP Gonzalez-Castellan and I’m the Accessibility Program Manager for IE8. The IE team has been working towards making IE8 the most accessible browser possible, and we wanted to detail some of the work we’ve done toward this end. In this post I will provide you with some background on Accessibility, I’ll cover new UI features (Caret Browsing, Find on Page, Adaptive Zoom, High DPI, etc) and also platform features (support for ARIA, support for IAccessibleEx, and support for additional WinEvents) that improve the Accessibility of the browser.</description>
	</item>
	<item>
		<title>Web Content Accessibility Guidelines (WCAG) 2.0</title>
		<link>http://tc.eserver.org/33471.html</link>
		<guid>http://tc.eserver.org/33471.html</guid>
		<description>Web Content Accessibility Guidelines (WCAG) 2.0 covers a wide range of recommendations for making Web content more accessible. Following these guidelines will make content accessible to a wider range of people with disabilities, including blindness and low vision, deafness and hearing loss, learning disabilities, cognitive limitations, limited movement, speech disabilities, photosensitivity and combinations of these. Following these guidelines will also often make your Web content more usable to users in general.</description>
	</item>
	<item>
		<title>A Personal Reflection on the WCAG 2.0 Publication</title>
		<link>http://tc.eserver.org/33472.html</link>
		<guid>http://tc.eserver.org/33472.html</guid>
		<description>Let&apos;s work together as a community to make WCAG 2.0 a unifying force for web accessibility. There are so many websites and exciting new web applications being created today with accessibility barriers that make it difficult or impossible for some people with disabilities to use them. Let&apos;s change that, with WCAG 2.0.</description>
	</item>
	<item>
		<title>Access 2.0</title>
		<link>http://tc.eserver.org/33473.html</link>
		<guid>http://tc.eserver.org/33473.html</guid>
		<description>The point of this blog is to look at all the things happening on the web now and in the future; the good, the bad and the downright fugly. But we&apos;ll be looking at it from the point of view of inclusivity.</description>
	</item>
	<item>
		<title>Accessing Information: Not Everyone Does it the Same Way</title>
		<link>http://tc.eserver.org/33475.html</link>
		<guid>http://tc.eserver.org/33475.html</guid>
		<description>As some in our profession have come to realize, social media and use of the Web in general have changed (and are still changing) the way in which people access and use information.</description>
	</item>
	<item>
		<title>This is How the Web Gets Regulated</title>
		<link>http://tc.eserver.org/33309.html</link>
		<guid>http://tc.eserver.org/33309.html</guid>
		<description>As in finance, so on the web: self-regulation has failed. Nearly ten years after specifications first required it, video captioning can barely be said to exist on the web. The big players, while swollen with self-congratulation, are technically incompetent, and nobody else is even trying. So what will it take to support the human and legal rights of hearing impaired web users? It just might take the law, says Joe Clark.</description>
	</item>
	<item>
		<title>Serving Citizens’ Needs: Minimising Online Hurdles to Accessing Government Information</title>
		<link>http://tc.eserver.org/33232.html</link>
		<guid>http://tc.eserver.org/33232.html</guid>
		<description>With the rapid spread of the Internet across society, government institutions are taking advantage of digital technology to distribute materials to citizens. Is merely having a website enough, or are there certain usability considerations site creators must keep in mind to assure efficient public access to online materials? This project looked at typical people&apos;s ability to locate various types of content online, in particular, their ability to find tax forms on the web. Findings suggest that people look for content in a myriad of ways, and there is considerable variance in how long people take to complete this online task. Users are often confused by the ways in which content is presented to them. In this paper, two common sources of confusion in users&apos; online experiences with locating tax forms online are distinguished: (1) URL confusion and (2) page design layout. Ways are also suggested to decrease these two sources of frustration, yielding less exasperating and more productive user experiences.</description>
	</item>
	<item>
		<title>Moving Towards Accessible Development</title>
		<link>http://tc.eserver.org/33212.html</link>
		<guid>http://tc.eserver.org/33212.html</guid>
		<description>Below is a bit of an accessibility round up of a few useful tools, articles, sites, and informative podcasts about the topic that may help inform/convince you about the importance of accessibility.</description>
	</item>
	<item>
		<title>The Guild of Accessible Web Designers</title>
		<link>http://tc.eserver.org/33192.html</link>
		<guid>http://tc.eserver.org/33192.html</guid>
		<description>The Guild of Accessible Web Designers (GAWDS) is a worldwide association of professional organisations, web designers and developers working together to promote the use and preservation of accessible design standards.</description>
	</item>
	<item>
		<title>Web Accessibility Network for Australian Universities</title>
		<link>http://tc.eserver.org/33195.html</link>
		<guid>http://tc.eserver.org/33195.html</guid>
		<description>We are an informal group of university people who share a common interest in web accessibility. Our members are from universities all over Australia.</description>
	</item>
	<item>
		<title>Analysis Phase</title>
		<link>http://tc.eserver.org/33114.html</link>
		<guid>http://tc.eserver.org/33114.html</guid>
		<description>It is most effective and efficient to incorporate accessibility from the very beginning of a project. When accessibility is only addressed late in product design, it can be very costly to make required design changes. Incorporating accessibility early in the project increases the potential positive design impact, and decreases the time and money required to design accessible products. This chapter provides information on setting usability goals, user analysis, workflow analysis and understanding accessibility issues.</description>
	</item>
	<item>
		<title>Build Accessible Online Forms</title>
		<link>http://tc.eserver.org/33132.html</link>
		<guid>http://tc.eserver.org/33132.html</guid>
		<description>Ask anyone who has had to fix a Website that&apos;s littered with accessibility howlers, and top-most in their list of problems encountered will be forms, closely followed by tables. These two topics always seem to present the most difficulties, but they needn&apos;t be a problem. For the most part, forms are a problem because the extra accessibility tags are simply not known to the Web designer -- after all, it looks right, it seems to work... what&apos;s the problem? Only by switching off the monitor and using a screen-reader can our oblivious Web developer understand the issues.</description>
	</item>
	<item>
		<title>Be a White Hat SEO for Your Intranet: It&apos;s Good for Accessibility</title>
		<link>http://tc.eserver.org/33046.html</link>
		<guid>http://tc.eserver.org/33046.html</guid>
		<description>The SEOs with white hats conduct legitimate optimising of web pages to make the site come up appropriately in the Search Engine Results Pages (also called SERPs). The back hat SEOs implement tricks to appear high in the results pages even if the web site is not necessarily relevant. The range of tricks is astonishing. But most of the techniques used by white hat SEOs were similar if not identical to the guidelines given by accessibility experts.</description>
	</item>
	<item>
		<title>Accessibility Humanized</title>
		<link>http://tc.eserver.org/32994.html</link>
		<guid>http://tc.eserver.org/32994.html</guid>
		<description>Most web developers act in blindness when they design accessible websites, since they know next to nothing about disabled people and the technology they use. Accessibility guidelines and validation tools doesn&apos;t provide this insight. Accessibility should rather be approached from a user centred perspective.</description>
	</item>
	<item>
		<title>Integrating Accessibility Throughout Design</title>
		<link>http://tc.eserver.org/32995.html</link>
		<guid>http://tc.eserver.org/32995.html</guid>
		<description>The Web is providing unprecedented access to information and interaction for people with disabilities. It provides opportunities to participate in society in ways otherwise not available. With accessible websites, people with disabilities can do ordinary things: children can learn, teenagers can flirt, adults can make a living, seniors can read about their grandchildren, and so on. With the Web, people with disabilities can do more things themselves, without having to rely on others. </description>
	</item>
	<item>
		<title>Appropriate Use of Alternative Text</title>
		<link>http://tc.eserver.org/32877.html</link>
		<guid>http://tc.eserver.org/32877.html</guid>
		<description>Adding alternative text for images is the first principle of web accessibility. It is also one of the most difficult to properly implement. The web is replete with images that have missing, incorrect, or poor alternative text. Like many things in web accessibility, determining appropriate, equivalent, alternative text is often a matter of personal interpretation. Through the use of examples, this article will present our experienced interpretation of appropriate use of alternative text.</description>
	</item>
	<item>
		<title>An Eight-Step Implementation Model</title>
		<link>http://tc.eserver.org/32879.html</link>
		<guid>http://tc.eserver.org/32879.html</guid>
		<description>The inaccessibility of web content can have a significant impact on the lives of individuals with disabilities. Many people without disabilities are ignorant of the importance of the issue to those who are directly affected. They are also often ignorant of the tremendous benefit that accessible web content can be. Accessible web sites offer independence to individuals with disabilities that would otherwise not have it.</description>
	</item>
	<item>
		<title>Links and Hypertext: An Introduction to Links and Hypertext</title>
		<link>http://tc.eserver.org/32880.html</link>
		<guid>http://tc.eserver.org/32880.html</guid>
		<description>Some types of links are more accessible than others, and some types of links are completely inaccessible to people with certain types of disabilities. Because links are so basic to the functionality of web content, inaccessible links are one of the most severe barriers to overall accessibility.</description>
	</item>
	<item>
		<title>Using JAWS to Evaluate Web Accessibility</title>
		<link>http://tc.eserver.org/32881.html</link>
		<guid>http://tc.eserver.org/32881.html</guid>
		<description>This article is designed to help users who are new to JAWS learn the basic controls for testing web content, and to serve as a reference for the occasional JAWS user.</description>
	</item>
	<item>
		<title>Testování Přístupnosti Webových Stránek se Screenreaderem JAWS</title>
		<link>http://tc.eserver.org/32882.html</link>
		<guid>http://tc.eserver.org/32882.html</guid>
		<description>Tento článek je českou verzí článku Using JAWS to Evaluate Web Accessibility. V textu jsou zmiňovány prvky stránky, které jsou součástí struktury webu WebAIM.org a nemusí se vyskytovat na stránce s touto verzí.</description>
	</item>
	<item>
		<title>Usando o Jaws Para Testar Acessibilidade</title>
		<link>http://tc.eserver.org/32883.html</link>
		<guid>http://tc.eserver.org/32883.html</guid>
		<description>Este artigo destina-se a ensinar aos usuários não familiarizados com o JAWS os procedimentos básicos necessários a avaliar a acessibilidade do conteúdo web e servir como uma espécie de guia de referência para o usuário ocasional deste programa.</description>
	</item>
	<item>
		<title>Web Accessibility podGuide</title>
		<link>http://tc.eserver.org/32885.html</link>
		<guid>http://tc.eserver.org/32885.html</guid>
		<description>The web accessibility podGuide is an iPod-ready version of the current web-related accessibility standards, including: Authoring Tools Accessibility Guidelines (ATAG 1.0); User Agent Accessibility Guidelines (UAAG 1.0); Web Content Accessibility Guidelines (WCAG 1.0); Section 508 standards for web, software, multimedia and related accessibility.</description>
	</item>
	<item>
		<title>How to Meet WCAG 2.0</title>
		<link>http://tc.eserver.org/32886.html</link>
		<guid>http://tc.eserver.org/32886.html</guid>
		<description>A customizable quick reference to Web Content Accessibility Guidelines 2.0 requirements (success criteria) and techniques.</description>
	</item>
	<item>
		<title>Accessites.org: The Art of Accessibility</title>
		<link>http://tc.eserver.org/32887.html</link>
		<guid>http://tc.eserver.org/32887.html</guid>
		<description>We aim to prove that accessible, usable web sites built with universality and standards in mind need not be boring. We will show you artfully crafted sites made by some of today’s most progressive web developers.</description>
	</item>
	<item>
		<title>A Quick and Dirty Introduction to Accessibility</title>
		<link>http://tc.eserver.org/32888.html</link>
		<guid>http://tc.eserver.org/32888.html</guid>
		<description>A presentation providing an overview of accessibility that discusses disabilities that affect use of the web, devices and technologies used by disabled users.</description>
	</item>
	<item>
		<title>Page Source Order and Accessibility</title>
		<link>http://tc.eserver.org/32889.html</link>
		<guid>http://tc.eserver.org/32889.html</guid>
		<description>In this presentation, the authors report on a survey and testing with screen reader users designed to determine how the placement of navigation in the source order (before or after content) affects accessibility.</description>
	</item>
	<item>
		<title>LD Web</title>
		<link>http://tc.eserver.org/32891.html</link>
		<guid>http://tc.eserver.org/32891.html</guid>
		<description>LD Web is a website aimed at making the Internet a better place for people with learning disabilities. LD Web develops guidelines and practical &quot;how to&quot; techniques to help web designers understand this underserviced community. LD Web is also meant to be an open discussion forum for dialogue, questions, and experiences in dealing with learning disabilities on the Web.</description>
	</item>
	<item>
		<title>Designing Usable Sites for Children and Teens</title>
		<link>http://tc.eserver.org/32894.html</link>
		<guid>http://tc.eserver.org/32894.html</guid>
		<description>It is often difficult for an adult designer to accurately remember what it is like to be 10 years old, and so it is important to turn to research conducted with children and teens to get a sense of their preferences.</description>
	</item>
	<item>
		<title>Usability of Websites for Teenagers</title>
		<link>http://tc.eserver.org/32903.html</link>
		<guid>http://tc.eserver.org/32903.html</guid>
		<description>When using websites, teenagers have a lower success rate than adults and they&apos;re also easily bored. To work for teens, websites must be simple -- but not childish -- and supply plenty of interactive features. </description>
	</item>
	<item>
		<title>Kids&apos; Corner: Website Usability for Children</title>
		<link>http://tc.eserver.org/32904.html</link>
		<guid>http://tc.eserver.org/32904.html</guid>
		<description>Our usability study of kids found that they are as easily stumped by confusing websites as adults. Unlike adults, however, kids tend to view ads as content, and click accordingly. They also like colorful designs, but demand simple text and navigation.</description>
	</item>
	<item>
		<title>Best Practices: Writing for Accessibility</title>
		<link>http://tc.eserver.org/32906.html</link>
		<guid>http://tc.eserver.org/32906.html</guid>
		<description>Most of the time, the primary focus of information about accessibility has to do with making non-text information available as text. Captioning and audio description for video, transcriptions for audio, simple text alternatives for static images. But what about the content itself?</description>
	</item>
	<item>
		<title>Web Design for Dyslexic Users</title>
		<link>http://tc.eserver.org/32907.html</link>
		<guid>http://tc.eserver.org/32907.html</guid>
		<description>How should a website homepage be created so that people with dyslexia can get the most out of the page?</description>
	</item>
	<item>
		<title>Adobe Acrobat and PDF</title>
		<link>http://tc.eserver.org/32909.html</link>
		<guid>http://tc.eserver.org/32909.html</guid>
		<description>After HTML, PDF (Portable Document Format) files are probably the most common files on the Web. PDF is usually used when a file needs to appear or print a certain way, regardless of the browser or technology. PDF files can be made accessible to people with disabilities, although usually with more difficulty than with HTML. A key part of this process involves creating tags that make a document more accessible to screen reader users.</description>
	</item>
	<item>
		<title>On Scalable Text</title>
		<link>http://tc.eserver.org/32911.html</link>
		<guid>http://tc.eserver.org/32911.html</guid>
		<description>In order to provide scalable text, make textual information text (rather than images), and use relative text sizes (rather than absolute). Scalable text is important for people with low vision. The basics of providing scalable text are very simple. However, strict design requests can pose challenges.</description>
	</item>
	<item>
		<title>How to Make Your Blog Accessible to Blind Readers</title>
		<link>http://tc.eserver.org/32912.html</link>
		<guid>http://tc.eserver.org/32912.html</guid>
		<description>So you have a blog, and you&apos;re worried that it might not be accessible to people with disabilities? Don&apos;t worry! A few simple changes can increase your blog&apos;s potential readership.</description>
	</item>
	<item>
		<title>Designing Web Content for People with Learning Disabilities</title>
		<link>http://tc.eserver.org/32914.html</link>
		<guid>http://tc.eserver.org/32914.html</guid>
		<description>We need to design sites to include as many people as possible so that we have a fairer world. We need accessibility to bridge differences and integrate more people into society. If someone who could understand Web content is unable to because of the design choices of the Web author, then that Web content is not as accessible as it could be - even if it can be used by all types of physically disabled users. </description>
	</item>
	<item>
		<title>Designing Pages Accessible to Limited Textual Comprehension Users</title>
		<link>http://tc.eserver.org/32915.html</link>
		<guid>http://tc.eserver.org/32915.html</guid>
		<description>Little has been written or done to advance the cause of web users with cognitive disabilities -- users who may actually require the use of graphics in order to make sense of a web site. For purposes of this document, we will use the term &quot;Limited Textual Comprehension&quot; to refer to anyone, disabled or not, who is unable to understand a web page -- and thus cannot access the information contained within in it -- due to the textual content of the page.</description>
	</item>
	<item>
		<title>How to Avoid Screen Reader &apos;Noise Pollution&apos;</title>
		<link>http://tc.eserver.org/32916.html</link>
		<guid>http://tc.eserver.org/32916.html</guid>
		<description>Surely there can&apos;t be a skill to writing ALT text for images? You just pop a description in there and you&apos;re good to go, right? Well, kind of. Sure, it&apos;s not rocket science, but there are a few guidelines you need to follow.</description>
	</item>
	<item>
		<title>Demonstration of the LONGDESC Attribute and the &apos;d&apos; Link</title>
		<link>http://tc.eserver.org/32917.html</link>
		<guid>http://tc.eserver.org/32917.html</guid>
		<description>When images are provided to illustrate complex ideas, the same information MUST also be provided in an accessible form.</description>
	</item>
	<item>
		<title>CSS in Action: Invisible Content Just for Screen Reader Users</title>
		<link>http://tc.eserver.org/32918.html</link>
		<guid>http://tc.eserver.org/32918.html</guid>
		<description>Most of the techniques for making web content accessible to screen readers are invisible to visual users. Alternative (alt) text, table header tags, table summaries, and form &lt;label&gt;  tags are examples of techniques that make a big difference for screen reader users, but which have little or no impact on the visual appearance of the web content.&#xD;&#xD;Every once in a while, though, web designers confront situations in which the addition of accessible markup does have an impact on the visual layout. In some cases, this visual impact can decrease the usability of the content for visual users. In other cases, designers simply want to provide a more pleasing layout or appearance that would be compromised by including all of the text in a semantically correct format.</description>
	</item>
	<item>
		<title>A More Accessible Map</title>
		<link>http://tc.eserver.org/32919.html</link>
		<guid>http://tc.eserver.org/32919.html</guid>
		<description>Most online mapping applications do not address issues of web accessibility. For a visually impaired web user, these highly visual maps are essentially useless. Is there a way to display text-based data on a map, keeping it accessible, useful and visually attractive? Yes: using an accessible CSS-based map in which the underlying map data is separated from the visual layout.</description>
	</item>
	<item>
		<title>A Dyslexic Perspective on e-Content Accessibility</title>
		<link>http://tc.eserver.org/32920.html</link>
		<guid>http://tc.eserver.org/32920.html</guid>
		<description>This paper gives the web developer an insight into the issues of web accessibility for users with dyslexia (and/or other specific learning difficulties). It covers the four main areas of accessibility: presentation, content, structure and navigation.</description>
	</item>
	<item>
		<title>Accessible Folksonomies</title>
		<link>http://tc.eserver.org/32921.html</link>
		<guid>http://tc.eserver.org/32921.html</guid>
		<description>I’ve been thinking about one particular artifact of the folksonomy phenomenon — the folksonomy menu that serves as a sort of buzz index providing users with a quick visualization of the most popular tags (technically I think it’s called a weighted list). Popular tags are displayed in a larger font and it’s relatively easy to identify hot topics at a glance. This visual representation of the popularity of any given tag is undeniably cool. However, once the coolness factor wears off it becomes fairly obvious that these menus are also not very accessible.</description>
	</item>
	<item>
		<title>Developing a Web Accessibility Business Case for Your Organization: Overview</title>
		<link>http://tc.eserver.org/32833.html</link>
		<guid>http://tc.eserver.org/32833.html</guid>
		<description>There are initial costs for organizations implementing Web accessibility; however, the initial costs are often offset by a full return on investment. In order to be willing to invest the initial costs, many organizations need to understand the social, technical, and financial benefits of Web accessibility and the expectations of the returns throughout the organization.</description>
	</item>
	<item>
		<title>Introduction to Web Accessibility</title>
		<link>http://tc.eserver.org/32834.html</link>
		<guid>http://tc.eserver.org/32834.html</guid>
		<description>Web accessibility means that people with disabilities can use the Web. More specifically, Web accessibility means that people with disabilities can perceive, understand, navigate, and interact with the Web, and that they can contribute to the Web. Web accessibility also benefits others, including older people with changing abilities due to aging.</description>
	</item>
	<item>
		<title>Ten Accessibility Blunders of the Big Players</title>
		<link>http://tc.eserver.org/32836.html</link>
		<guid>http://tc.eserver.org/32836.html</guid>
		<description>More and more countries have passed laws stating that Websites must be accessible to blind and disabled people. With this kind of legal pressure, and the many benefits of accessibility, the big players on the Web must surely have accessible Websites, right?</description>
	</item>
	<item>
		<title>Ten Reasons Clients Don&apos;t Care About Accessibility</title>
		<link>http://tc.eserver.org/32837.html</link>
		<guid>http://tc.eserver.org/32837.html</guid>
		<description>Working as an accessibility consultant in an IT company is a very frustrating job right now. Highly publicized lawsuits and deep-rooted accessibility myths leave us with a lot to explain when the final product does not really help visitors. Our clients simply don’t care about accessibility as much as we’d like them to, and there are several reasons for that.</description>
	</item>
	<item>
		<title>Accessibility as Part of The Search Engine Marketing Strategy</title>
		<link>http://tc.eserver.org/32838.html</link>
		<guid>http://tc.eserver.org/32838.html</guid>
		<description>In traditional marketing you&apos;re looking to define your targeted audience for your business or organisation. In Internet marketing things work in the same way. Unfortunately, with the growing popularity of the Internet in the past years and with the growing number of people building sites, a certain part of the online audience has been overlooked.</description>
	</item>
	<item>
		<title>Accessibility Is Just Another Language</title>
		<link>http://tc.eserver.org/32839.html</link>
		<guid>http://tc.eserver.org/32839.html</guid>
		<description>Although typically we think of accessibility in terms of visual, hearing, dexterity, cognitive disabilities and so on, this concept of disability is very limiting in terms of the need for accessible technology. More than 50 million Americans have some sort of disability, and the numbers are increasing as the population ages. Tens of millions of people in the European Union (EU) and half a million worldwide have a disability. Disability knows no boundaries, languages or borders.</description>
	</item>
	<item>
		<title>Accessibility Issues Make a Difference</title>
		<link>http://tc.eserver.org/32840.html</link>
		<guid>http://tc.eserver.org/32840.html</guid>
		<description>You often read advice from industry experts along the lines of &quot;using tags as they were meant to be used&quot; and limiting your use of advanced programming techniques in order to make your site accessible.</description>
	</item>
	<item>
		<title>Accessibility Tips for Website Construction</title>
		<link>http://tc.eserver.org/32841.html</link>
		<guid>http://tc.eserver.org/32841.html</guid>
		<description>This paper provides ten key tips to help improve the accessibility of any website, or intranet. It&apos;s not intended to be an introduction to web accessibility.</description>
	</item>
	<item>
		<title>Accessible By Design</title>
		<link>http://tc.eserver.org/32842.html</link>
		<guid>http://tc.eserver.org/32842.html</guid>
		<description>The demand for accessible sites is growing, but web workers, like you, are often unclear how to make sites more accessible. Designing an accessible site isn&apos;t necessarily harder, but it involves unique limitations that make you approach design from a different perspective.</description>
	</item>
	<item>
		<title>Assessing Assessments: The Inequality of Electronic Testing</title>
		<link>http://tc.eserver.org/32843.html</link>
		<guid>http://tc.eserver.org/32843.html</guid>
		<description>Computer and Internet based tests are used for a variety of purposes. From entering education or employment, to improving basic learning, people everywhere are taking electronically formatted tests. With the advancement of testing from traditional paper-based tests to technologically advanced electronic tests, people reap the benefits of easier access to tests, faster response times, and greater reliability and validity of tests. However, persons with disabilities are being left out of the picture and out of many typically-administered tests.</description>
	</item>
	<item>
		<title>Attitudes to Web Accessibility</title>
		<link>http://tc.eserver.org/32844.html</link>
		<guid>http://tc.eserver.org/32844.html</guid>
		<description>During the summer of 2003, we ran an online questionnaire, conducted interviews and carried out a literature review on Web accessibility. One hundred and seventeen respondents participated and they included designers, information officers and accessibility advocates. This initial set of results are intended to encourage debate on the subject.</description>
	</item>
	<item>
		<title>The Benefits of an Accessible Website, Part 1: Increase in Reach</title>
		<link>http://tc.eserver.org/32845.html</link>
		<guid>http://tc.eserver.org/32845.html</guid>
		<description>Some organisations are making accessibility improvements to their websites, but many are seemingly not making the accessibility adjustments. Disabled people don&apos;t access their website, they say, so why should they care?</description>
	</item>
	<item>
		<title>The Benefits of an Accessible Website, Part 2: The Business Case</title>
		<link>http://tc.eserver.org/32846.html</link>
		<guid>http://tc.eserver.org/32846.html</guid>
		<description>Some organisations are making accessibility improvements to their websites, but many are seemingly not making the accessibility adjustments. Disabled people don&apos;t access their website, they say, so why should they care?</description>
	</item>
	<item>
		<title>Building a Barrier-Free Web</title>
		<link>http://tc.eserver.org/32847.html</link>
		<guid>http://tc.eserver.org/32847.html</guid>
		<description>Perhaps you&apos;re not legally required to make your site friendly to disabled users, but it&apos;s still good business.</description>
	</item>
	<item>
		<title>Captcha Usability Revisited: Google Inaccessible to Blind People</title>
		<link>http://tc.eserver.org/32848.html</link>
		<guid>http://tc.eserver.org/32848.html</guid>
		<description>An online petition is being circulated to all Internet users for the purpose of collecting signatures showing support for Google to make its word verification scheme accessible to the blind and visually impaired.</description>
	</item>
	<item>
		<title>Constructing a POUR Website - Putting People at the Center of the Process</title>
		<link>http://tc.eserver.org/32850.html</link>
		<guid>http://tc.eserver.org/32850.html</guid>
		<description>Web developers can create Web sites that are possible for people with disabilities to access, but only with great difficulty. The technical standards are important, but they may be insufficient on their own. Developers need to learn when and how to go beyond the technical standards when necessary.</description>
	</item>
	<item>
		<title>Developing and Publicising a Workable Accessibility Strategy</title>
		<link>http://tc.eserver.org/32851.html</link>
		<guid>http://tc.eserver.org/32851.html</guid>
		<description>This article looks at the increasing need for developers of institutional and educational websites to develop and follow a strategy for ensuring optimal accessibility of online content. In particular the need is stressed for careful thought about the aims of such a strategy, and to ensure that the strategy meets a balance between ambition, legal responsibility and equitable access to learning and teaching. As an example, the need for a well written public online accessibility statement is discussed, not only as a demonstration of awareness and proactivity, but also as an important factor in its own right in optimising access.</description>
	</item>
	<item>
		<title>Essential Components of Web Accessibility</title>
		<link>http://tc.eserver.org/32852.html</link>
		<guid>http://tc.eserver.org/32852.html</guid>
		<description>This document shows how Web accessibility depends on several components working together and how improvements in specific components could substantially improve Web accessibility. It also shows how the WAI guidelines address these components.</description>
	</item>
	<item>
		<title>How Will the New Disability Standards for Education Affect What Universities Do on the Web?</title>
		<link>http://tc.eserver.org/32853.html</link>
		<guid>http://tc.eserver.org/32853.html</guid>
		<description>On August 18, 2005 new Disability Standards for Education came into effect in Australia. Questions have been raised about how they may impact on the way universities publish resources on the web. In this article, I provide an overview of the new Standards, their general impact, and conclude that if organisations are already following the advice of the Human Rights and Equal Opportunity Commission (on how to comply with the Disability Discrimination Act 1992 in relation to the web), the introduction of the Standards should make no appreciable difference.</description>
	</item>
	<item>
		<title>Inaccessible Website Demo</title>
		<link>http://tc.eserver.org/32854.html</link>
		<guid>http://tc.eserver.org/32854.html</guid>
		<description>When people consider disability and web use they often only think of blind people. But of course there are many types of disability which need to be considered when designing web pages. In this demonstration we try to give you a flavour of the kind of difficulties a range of disabled visitors can face.</description>
	</item>
	<item>
		<title>Innovative Design Inspired by Accessibility</title>
		<link>http://tc.eserver.org/32855.html</link>
		<guid>http://tc.eserver.org/32855.html</guid>
		<description>To design innovative Web applications that create opportunities rather than barriers, study the variety of characteristics of people, situations, and devices in your audience--it will give you new perspective from which to approach your design.</description>
	</item>
	<item>
		<title>Keys to Access: Accessibility Conformance in VET</title>
		<link>http://tc.eserver.org/32856.html</link>
		<guid>http://tc.eserver.org/32856.html</guid>
		<description>In this research, we aimed to investigate what VET training providers have achieved in terms of accessibility conformance; to reveal and understand the obstacles that may be blocking conformance and suggest strategies that will speed conformance.</description>
	</item>
	<item>
		<title>Manchester United: Top of the Web Accessibility League?</title>
		<link>http://tc.eserver.org/32858.html</link>
		<guid>http://tc.eserver.org/32858.html</guid>
		<description>Manchester United have received a lot of press coverage for the separate accessible version of their website. They&apos;ve probably invested a lot of time and effort to make this separate website, which according to Trenton Moss is totally unnecessary.</description>
	</item>
	<item>
		<title>Screen Readers and CSS Layout</title>
		<link>http://tc.eserver.org/32859.html</link>
		<guid>http://tc.eserver.org/32859.html</guid>
		<description>Screen readers are mostly mystical devices for almost all of us. Few of us actually own them. They’re incredibly expensive. Fewer yet know how to use them well, what their capabilities are, or how they actually work. Is it little wonder then, that big names in our web design world question how screen readers handle modern layout techniques? Not at all. The two gurus quoted below have other strengths, and specialities. They probably haven’t used a screen reader in ages.</description>
	</item>
	<item>
		<title>Screen-Reader Usability at a Standards-Compliant E-Commerce Site</title>
		<link>http://tc.eserver.org/32860.html</link>
		<guid>http://tc.eserver.org/32860.html</guid>
		<description>An E-commerce site was redesigned with Web standards in mind. The revised site used semantic HTML markup that usually passes validation tests and also incorporated many common accessibility features. A study was carried out with screen-reader users to determine how well compliance with Web standards and accessibility guidelines translated into actual usability and accessibility. </description>
	</item>
	<item>
		<title>Secret Benefits of Accessibility Part 1: Increased Usability</title>
		<link>http://tc.eserver.org/32861.html</link>
		<guid>http://tc.eserver.org/32861.html</guid>
		<description>Web accessibility has so many benefits that I really do wonder why such a large number of Websites have such diabolically bad accessibility. One of the main benefits is increased usability, which, according to usability guru, Jakob Nielsen, can increase the sales/conversion rate of a Website by 100%, and traffic by 150%.</description>
	</item>
	<item>
		<title>Secret Benefits of Accessibility Part 2: Better Search Ranking</title>
		<link>http://tc.eserver.org/32862.html</link>
		<guid>http://tc.eserver.org/32862.html</guid>
		<description>One of the main benefits of Web accessibility is that a Website that&apos;s more accessible to people is also usually more accessible to search engines. The more accessible your site is to search engines, the more confidently they can guess what the site&apos;s about, giving your site a better chance at the top spot in the search engine rankings.</description>
	</item>
	<item>
		<title>Seven Accessibility Mistakes (Part 1)</title>
		<link>http://tc.eserver.org/32863.html</link>
		<guid>http://tc.eserver.org/32863.html</guid>
		<description>There are several reasons inaccessible Web products get published. One we discussed in my last article is that some clients just don’t care about accessibility. Their reasons make a lot of sense if you put yourself in their shoes. Another reason is developer mistakes. Making mistakes is natural, and suffering the consequences and learning from them is what makes us better developers and better people.</description>
	</item>
	<item>
		<title>Seven Accessibility Mistakes (Part 2)</title>
		<link>http://tc.eserver.org/32864.html</link>
		<guid>http://tc.eserver.org/32864.html</guid>
		<description>This two part-article discusses reasons why some projects fail to result in properly accessible products.</description>
	</item>
	<item>
		<title>Seven Screen Reader Usability Tips</title>
		<link>http://tc.eserver.org/32865.html</link>
		<guid>http://tc.eserver.org/32865.html</guid>
		<description>Simply ensuring that your Website is accessible to screen reader users is, unfortunately, not enough to guarantee that these users can find what they&apos;re looking for in a reasonably quick and efficient manner. Even if your site is accessible to screen reader users, its usability could be so poor that they needn&apos;t have bothered stooping by in the first place.</description>
	</item>
	<item>
		<title>Speaking ALT Text</title>
		<link>http://tc.eserver.org/32866.html</link>
		<guid>http://tc.eserver.org/32866.html</guid>
		<description>I have a few late model screen readers and I also have simple audio recording tools. I&apos;ll use them to get you closer to what these screen readers actually say. I&apos;ll start a collection of recordings so you can hear for yourself what these tools say.</description>
	</item>
	<item>
		<title>The Convergence of the Aging Work Force And Accessible Technology</title>
		<link>http://tc.eserver.org/32867.html</link>
		<guid>http://tc.eserver.org/32867.html</guid>
		<description>This paper discusses the effects of America’s aging work force on business growth and productivity and illustrates how accessible technology can equip employers and mature workers to face the challenges posed by this demographic trend.</description>
	</item>
	<item>
		<title>The Lifecycle of Web Accessibility</title>
		<link>http://tc.eserver.org/32868.html</link>
		<guid>http://tc.eserver.org/32868.html</guid>
		<description>In this article we&apos;ll divide the life cycle of web accessibility into 5 different phases and we&apos;ll see how they are strictly interconnected with other disciplines such as graphic design, development and content management.</description>
	</item>
	<item>
		<title>WCAG and the Myth of Accessibility</title>
		<link>http://tc.eserver.org/32871.html</link>
		<guid>http://tc.eserver.org/32871.html</guid>
		<description>Kevin Leitch explains why he feels that the Web Content Accessibility Guidelines have failed in their mission to ensure that web content is accessible to all.</description>
	</item>
	<item>
		<title>Understanding Disabilities when Designing a Website</title>
		<link>http://tc.eserver.org/32635.html</link>
		<guid>http://tc.eserver.org/32635.html</guid>
		<description>This article will explain some simple techniques which, if incorporated into the design of a website, will enhance its accessibility and usability for people who have a vision, hearing, physical, cognitive, or learning disability.</description>
	</item>
	<item>
		<title>Captions for Video with Flash CS3 (Part Two)</title>
		<link>http://tc.eserver.org/32623.html</link>
		<guid>http://tc.eserver.org/32623.html</guid>
		<description>In this article, we’re going to look at a method of captioning a Flash video file: embedding the XML directly into the FLV file. In very simple terms, the XML document will contain the cue points for the captions. When one of those cue points is reached, the caption appears over the video.</description>
	</item>
	<item>
		<title>Captions for Video with Flash CS3</title>
		<link>http://tc.eserver.org/32624.html</link>
		<guid>http://tc.eserver.org/32624.html</guid>
		<description>In the exercise that follows, and in the second part of this series, we are going to add captions, using both methods, to the same video. For those passionate about web standards, the first method involves the use of Timed Text captions. If you go this route, you need to follow the standard laid out by the W3C. There is a lot to it but, in a nutshell, it requires you to create a specific type of XML document using the required tags.</description>
	</item>
	<item>
		<title>How to Add Voice Interactivity to Your Site</title>
		<link>http://tc.eserver.org/32548.html</link>
		<guid>http://tc.eserver.org/32548.html</guid>
		<description>This tutorial aims to help you add voice interactivity to your site, with minimal code changes and maximal browser compatibility. Along the way, examples will be provided, and at the end, you will be able to test a fully working, real World, voice-enabled site. This tutorial describes the use of a reusable VoiceXML form.&#xD;&#xD;Because the voice capability is included in the browser, you do not need to write your own speech recognition engine or speech synthesizer. This is a great advantage to you and to your Web application users.</description>
	</item>
	<item>
		<title>Introduction to WAI ARIA</title>
		<link>http://tc.eserver.org/32516.html</link>
		<guid>http://tc.eserver.org/32516.html</guid>
		<description>This article is for those who are new to ARIA. You need an understanding of HTML and the potential difficulties that people with disabilities can face using the Web. It is useful to be familiar with some Rich Internet Applications from a user&apos;s perspectiveAfter reading this article, you&apos;ll understand what ARIA is for, how to integrate it into your sites, and how you can use it now to make even the simplest of sites more accessible.</description>
	</item>
	<item>
		<title>Building Accessible Static Navigation with CSS</title>
		<link>http://tc.eserver.org/32518.html</link>
		<guid>http://tc.eserver.org/32518.html</guid>
		<description>When building a navigation menu for a web site, steps should be taken to ensure that it is accessible, and degrades gracefully in older browsers with lesser CSS support. In this article we will explore one such implementation. The navigation menu you see in this example is built with valid, semantic HTML and CSS - no JavaScript is involved, as I felt this was unnecessary. The static (non-expanding/collapsing) nature of the example suits a web site comprised of twenty or less target pages.</description>
	</item>
	<item>
		<title>Replacing NOSCRIPT with Accessible, Unobtrusive DOM/JavaScript</title>
		<link>http://tc.eserver.org/32519.html</link>
		<guid>http://tc.eserver.org/32519.html</guid>
		<description>Modern user agents with JavaScript enabled will hide content contained within NOSCRIPT, and reveal it when JavaScript is disabled. User agents that do not support JavaScript will display the content within it. User agents with partial/antiquated JavaScript capabilities however interpret the element correctly and do not show the content, but when JavaScript is disabled also do not show the content - it never gets seen. This has an impact on the accessibility of the content. If your writing is targeted at modern, standards-based, compliant, and fully capable JavaScript user agents, employing the NOSCRIPT element is no problem. If the user agents among your audience are unpredictable, however, replacing the NOSCRIPT element with another mechanism becomes significant. This article looks at one such solution.</description>
	</item>
	<item>
		<title>Creating Accessible Data Tables</title>
		<link>http://tc.eserver.org/32520.html</link>
		<guid>http://tc.eserver.org/32520.html</guid>
		<description>This article demonstrates how to code accessible data tables in (X)HTML, enabling visually impaired users who employ assistive technologies to interpret the table data. Two views of a tabular data table are presented and discussed.</description>
	</item>
	<item>
		<title>XHTML Voice in Style</title>
		<link>http://tc.eserver.org/32523.html</link>
		<guid>http://tc.eserver.org/32523.html</guid>
		<description>This article builds upon topics in the XHTML Voice by Example article. A knowledge of CSS is also assumed.</description>
	</item>
	<item>
		<title>Getting to Know Voice</title>
		<link>http://tc.eserver.org/32524.html</link>
		<guid>http://tc.eserver.org/32524.html</guid>
		<description>From a different world than the traditional browsing world comes a range of techniques that allows a developer to code for speech behaviours much easier than previously possible. Opera has early support for this. W3C is working on standards for combining speech and the ordinary graphical user interface.</description>
	</item>
	<item>
		<title>Stop Using Ajax!</title>
		<link>http://tc.eserver.org/32527.html</link>
		<guid>http://tc.eserver.org/32527.html</guid>
		<description>We got things like browser wars, browser-specific DHTML, and table-based layouts. These were things that got in the way of the original vision, because people wanted rich content when the technology wasn’t ready. And now it’s happening again.</description>
	</item>
	<item>
		<title>Grid Design Basics: Grids for Web Page Layouts</title>
		<link>http://tc.eserver.org/32532.html</link>
		<guid>http://tc.eserver.org/32532.html</guid>
		<description>Since tables were co-opted for layout purposes, columns have become key to many Web design layouts, and this thinking continued when CSS took over from tables (at least in the minds of savvy designers) for Web-page presentation. However, other fields of layout design don’t think in arbitrary columns, they work with grids, and these form the basis for the structure of page designs. This article will provide the lowdown on grid design for Web pages.</description>
	</item>
	<item>
		<title>Introduction to Screen Readers</title>
		<link>http://tc.eserver.org/32485.html</link>
		<guid>http://tc.eserver.org/32485.html</guid>
		<description>Begins by showing us the core functionality of screen readers and how they interact with the desktop. In the second part it demonstrates how a blind user may use them to explore and understand web sites, how sites are “linearized”, and how using semantic markup to build sites supports accessible navigation and usability.</description>
	</item>
	<item>
		<title>Introduction to Screen Magnifiers</title>
		<link>http://tc.eserver.org/32486.html</link>
		<guid>http://tc.eserver.org/32486.html</guid>
		<description>Karo Caran and Victor Tsaran show how the screen magnifier ZoomText is used to make the computer desktop and web sites readable to people with reduced vision.</description>
	</item>
	<item>
		<title>From the Mouth of a Screenreader</title>
		<link>http://tc.eserver.org/32487.html</link>
		<guid>http://tc.eserver.org/32487.html</guid>
		<description>Talks about the history of screen reading software and how they analyse what is displayed on the screen in order to speak it to the user.</description>
	</item>
	<item>
		<title>Accessible Expanding and Collapsing Menu</title>
		<link>http://tc.eserver.org/32496.html</link>
		<guid>http://tc.eserver.org/32496.html</guid>
		<description>A website’s navigation should, in my opinion, be visible and straightforward, not hidden away like this or in flyout/dropdown menus. But...</description>
	</item>
	<item>
		<title>Unobtrusive and Keyboard Accessible Connected Select Boxes</title>
		<link>http://tc.eserver.org/32506.html</link>
		<guid>http://tc.eserver.org/32506.html</guid>
		<description>Any web developer who has created a reasonably complex form is probably aware of the concept of multiple select elements that are connected – choosing something from one select box either makes a new select box appear or changes the options of one that is already visible.</description>
	</item>
	<item>
		<title>The Language of Accessibility</title>
		<link>http://tc.eserver.org/32508.html</link>
		<guid>http://tc.eserver.org/32508.html</guid>
		<description>Good markup is accessible by default. As long as you’re using HTML elements in a semantically meaningful way—which you should be doing anyway, without even thinking about accessibility—then your documents will be accessible to begin with.</description>
	</item>
	<item>
		<title>Multiple Form Labels and Screen Readers</title>
		<link>http://tc.eserver.org/32425.html</link>
		<guid>http://tc.eserver.org/32425.html</guid>
		<description>Just about every website needs some forms. Sometimes there are many of them, sometimes just a single contact form. Regardless of their number, they need to be usable and accessible, which can sometimes be a little more work than it would be if theory and practice aligned a little better.</description>
	</item>
	<item>
		<title>Helping Others Understand Web Accessibility</title>
		<link>http://tc.eserver.org/32441.html</link>
		<guid>http://tc.eserver.org/32441.html</guid>
		<description>When I hold workshops for people who want to learn more about web standards and accessibility, I often notice that the attendants really have tried to improve their accessibility knowledge. But they get overwhelmed when they go to the official documentation from the W3C and try to understand it.</description>
	</item>
	<item>
		<title>Making Web Accessibility Accessible</title>
		<link>http://tc.eserver.org/32442.html</link>
		<guid>http://tc.eserver.org/32442.html</guid>
		<description>when first learning web accessibility and uncovering its secrets, like many things, it can seem daunting and difficult. I think a lot of developers are downright intimidated by web accessibility — maybe even scared to go that route. But why? I suspect the reason is web accessibility is a discipline that lacks accessibility.</description>
	</item>
	<atom:link href="http://tc.eserver.org/dir/Web-Design/Accessibility.xml" rel="self" type="application/rss+xml"/>
</channel>
</rss>