Blog » Archive by category 'Web Development'
On occasion, I’ve needed to add various pieces of software to sites I’ve designed or modified. Particularly with database-driven projects I’ve found myself needing to heavily modify scripts I’ve found or simply write my own in order to massage the produced markup into some vestiges of accessibility.
Although I make no claims of perfection, I’ve recently posted three new articles in the articles section of this site:
None of these articles is going to provide you with rich, production-grade software or techniques for a large, heavily trafficked site. However, they should be easily sufficient to make it easy for you to add some small additional features to your
website which produces clean, valid markup.
Tags:
Inline linking is the practice of incorporating hyperlinks into text passages within the main body of your website. Generally, this is a technique for providing contextual explanations or additional information as an immediately accessible resource for site visitors. I recently read two articles concerning this subject - the first, at Wolf-Howl questions the practice of inline linking as being bad for usability. The second, by Bill Slawski, discusses Graywolf’s ideas.
Both articles make a number of valid points - but I feel that the overall question is a matter of preference. Personally, I find the presence of links within a contextual body to be extremely valuable. For context, there’s nothing to beat it. Graywolf suggests that lists of links following the text are less disruptive to the flow of reading. This may be true, in certain circumstances. I certainly agree that it helps in the specific example he provides. However, it seems to me that what he suggests only works for short, tightly focused texts.
In his example, a single paragraph is followed by four helpful links. Given this density of contextual links and the length of the content, this is clearly useful. However, provided with a document which is significantly longer - a 1500 word article, for example, this technique would be rather clumsy. Either you would end up with a block of links every couple of paragraphs, which I feel would disrupt my reading quite significantly, or you have a lengthy set of links at the foot of the document - which may provide insufficient context to be clear on the referenced point.
I have to think about this from an accessibility standpoint, as well. If the links are provided only at the end of the article, a user with a screen reader has a significant amount of ground to cover before they can reach any further information. With contextual links, the user can decide right away if they’re interested in additional information. Either way, they can use keyboard navigation to quickly skip from link to link - but with links only available in the footer, it’s may be very difficult to quickly identify the context of the link.
I also mentioned the post by Bill Slawski. One talent that Bill has is the ability to aggregate a huge number of relevant sources on a subject very quickly. Bill points out several references I thought were very apropos, including information from Jakob Nielsen, the usability guru, the psychology department at Wichita State University, and others.
Bill doesn’t come down firmly on one side or the other - which I think is very fair. There are advantages and disadvantages every way you cut it for linking — - either they’re disruptive or they’re convenient. They’re collected for easy reference or they’re separated for their immediate context. It’s always a choice you need to make — - link to the most important references within your text, and leave a collection of additional links at the end of the article may be the best choice.
And always provide well structured internal navigation!
Tags:
To Hell with WCAG 2.0 is the response from the author of Building Accessible Websites to the latest production of the W3C’s Web Accessibility Initiative.
Clearly, Joe Clark is not happy. And he’s not the first person to express dissatisfaction with the process and results of WCAG 2.0, either. John Foliot of Web Accessibility Technical Services has frequently expressed displeasure with their new yet fundamentally unchanged interpretation of the accesskey functionality.
In an effort to be all things to all web content, the fundamentals of WCAG 2 are nearly impossible for a working standards-compliant developer to understand. WCAG 2 backtracks on basics of responsible web development that are well accepted by standardistas.
Joe Clark, "To Hell with WCAG 2.0"
The three fundamental documents involved in the WCAG 2.0 package are the Web Content Accessibility Guidelines 2.0 (72 pages), Understanding WCAG 2.0, (165 pages), and Techniques for WCAG 2.0, which clocks in at 221 pages. Altogether, 448 pages of semi-legalese attempting to define the next generation of web pages.
No, these documents are not easy to understand. And they clearly contain a lot of extreme generalities which appear to be attempting to explain accessibility without reference to technologies. As Clark mentions, this separation of technology and theory makes it much more difficult to apply concepts to the practicalities of creating a website.
Joe Clark’s article is a must read towards understanding the politics and complexities of creating an accessible website. Accessibility is not about enslaving your design aesthetic to a set of guidelines - but it is about considering very carefully the needs of your users, testing your work, and making thoughtful decisions.
Tags:
SiteMorse, for those of you who may not know, is a high-profile accessibility testing company based in the United Kingdom. They are well-known for the practice of releasing their "Rankings League Tables," which list the tested accessibility of government, banking, and other websites each month.
Their particularly product is entirely automated - and has, therefore, been attacked quite heavily in the world of accessibility auditors and consultants.
At the moment, there is a very interesting conversation going on at
Accessify Forum which is primarily a question and answer session between Grant Broome, a well-reputed accessibility consultant working with CDSM Interactive Solutions and Jon Ribbens, a director of the company which develops the SiteMorse product.
I will disclose, to start, the fact that I was already in the anti-SiteMorse camp before reading this interview. However, to date the Q & A session has done little to change my views. It’s my feeling that Jon has done little but attempt to avoid Grant’s question. With repeated accusations about vagueness and the irrelevance of Grant’s questions and points, Jon has done little to impress me with his company’s dedication to accessibility issues.
The core issue is whether automated testing can possibly fully address the accessibility of a website. I and many other accessibility consultants believe, quite strongly, that it’s simply not possible to judge a website entirely based on automated judgements. An automated tool can be helpful for resolving specific issues - but should NEVER be substituted for a human appraisal of accessibility.
Regardless, this conversation has already been quite interesting, and is worth following.
Tags:
Since this article has been linked to now by a number of sites, I thought I’d provide a link to the actual post I wrote on AJAX and accessibility, to which this post is a follow-up! And, if you’re interested in a more recent and extensive article, try Accessibility and Usability Issues with AJAX, from October of 2007.
The incredible flexibility provided by Ajax technologies is a big frustration to the accessible design community. Speaking for myself, I’d LOVE to feel comfortable using these powerful tools to create accessible tools. But the situation continues to be limiting.
The limitations are, as I believe I’ve mentioned, at least partially contained in the way screen readers handle JavaScript events. Most non-visual browsers can support certain elements of JavaScript. Others don’t work as expected or at all! Any event which occurs upon the press of a mouse button is likely to be seriously limited, for example.
Recently, James Edwards has published a great article on Ajax accessibility at SitePoint.com. This article investigates in depth the behaviors of various screen readers with Ajax driven responses.
It’s great information, and I can only hope that it’ll inspire the designers of screen reader technology to work forward and build new functionality! For now, it mostly confirms just how unusable Ajax technologies are today.
Tags:
AJAX, or Asynchronous Javascript and XML, is one of the latest popular technologies to drop into a web developer’s bag of tricks. Although quite complicated to work with, the technique can provide an incredible variety of rich web application methods to work with. If you’ve ever visited any of the myriad "Web 2.0" applications, one common feature is the use of AJAX technologies.
The fundamental principle behind AJAX programming is that it works, as in the name, asynchronously. Most interactive web programming requires regular requests to a server. The general information flow is that you, the user, request a document. That document contains a form, where you fill in your information. You press submit, the page sends your information to the server, which does something with it such as signing you up for a mailing list, and then sends back a response - usually, an indication of success or failure.
In this process, every request requires a full refresh of the web page. However, AJAX works differently. Using the ability of Javascript to manipulate the DOM of a page (that is, edit page elements without refreshing) combined with the ability to make XML requests to the server, AJAX can send queries to the server and post the response to the web page without performing a page refresh.
For a web application, this is tremendous - although a server request may not actually be any faster than it was before, a programmer can now create a site which reacts to the information a user puts into the site instantaneously. Handling the server request no longer interrupts whatever the user is doing - they can continue working, reading, or moving ahead without having to wait each time for the page to refresh.
But! (And you knew there would be a but!) Accessibility and dynamic behavior have always had some significant conflicts. In a traditional format, a page refreshes and a user simply has to start reading from the beginning. Usually, at the beginning of the content section of the page, there will be a notice of what has happened - either "this section was not filled out" or "your submission was successful", or some response to that effect. Very easy to deal with from an accessibility point of view. AJAX changes all that. Suddenly, a dynamic site is updating areas all over the page without a refresh. How does a blind user know that anything has changed? To a visual user, you can see that a section of the page blanks out and refreshes. The content is now different. A blind user sees nothing, experiences no change.
This obvious issue with refreshing data is not the only accessibility concern with AJAX and DHTML. Thankfully, the new popularity of the AJAX technology family has spurred many large organizations to pioneer new methods of managing accessibility for dynamic technologies. Recently, the Mozilla Foundation teamed up with IBM to establish DHTML accessibility in Mozilla’s open-source browser, Firefox.
This accessibility is still rudimentary - but it’s definitely a start. The W3C has also begun to establish their own roadmap towards accessible dynamic content, having released their working draft on April 5th, 2006.
At this time, I will only employ AJAX in very limited circumstances - usually, for administrative backends where I can be certain that only a few specific people will have need to use it, and I can be assured that I will not be creating problems for others. However, the day may yet come when AJAX technologies are ready for truly accessible use.
Tags:
It’s a common misapprehension that making an accessible website is expensive. Not exactly true - it’s more accurate to state that it’s expensive to make a website accessible. There is a subtle distinction between those two statements, but an important one.
The same is true in most issues regarding accessibility - it’s not significantly more expensive to make a building, a voting terminal, or a digital resource reasonably accessible from the beginning than it would be otherwise. However, it’s always significantly more expensive to retrofit your existing building to be accessible. You have to widen doorways, build ramps, replace bathroom fittings, etc. The same is true for a website - it’s not a simple matter to make a website accessible if it has previously been built in a less acceptable manner.
Part of what makes a website truly accessible is providing valuable, unique information embedded in the code. Writing alt tags which are descriptive and helpful, writing long descriptions of complex graphs and other visual aids, or providing meanings for acronyms and abbreviations. This is detailed work - and you can’t easily take shortcuts.
Automation is sometimes an incredibly valuable aid, but it’s too easy to perceive it as a solution. Making a website accessible takes time, patience, and attention to detail.
Tags:
Return to Top
