{"id":64,"date":"2005-01-18T00:09:41","date_gmt":"2005-01-18T08:09:41","guid":{"rendered":""},"modified":"2016-05-25T23:34:38","modified_gmt":"2016-05-26T06:34:38","slug":"server-side-accessibility","status":"publish","type":"post","link":"https:\/\/mikeindustries.com\/blog\/archive\/2005\/01\/server-side-accessibility","title":{"rendered":"Does Accessibility Belong on the Server-Side?"},"content":{"rendered":"

\"\"If you think you knew how to design or code a site with disabled people in mind, head on over to this National Institute of Standards and Technology accessibility study<\/a> (via: Henrik Olsen<\/a>) and find out exactly how much you don’t<\/em> know.<\/p>\n

Somewhere in Toronto, even Joe Clark<\/a> is taking notes.<\/p>\n

In a nutshell, Redish & Associates<\/a> observed 22 screenreader users interact with a variety of web sites. Most were government sites, but Google was also included to represent search behavior. The results showed that most sites, whether or not they complied with the syntax<\/em> of accessibility, were difficult to use based on the presentation<\/em> of the content.<\/p>\n

The study covers lots of ground, all the way from “skip navigation” links to recommendations against creating branded words like “LiveHelp” (apparently, screenreaders read that as “livahelp”).
\n
\nOne particularly humbling thing about the study is that it shows exactly how little effort goes into testing<\/em> for usable accessibility. I’m guilty of it myself and so is 99% of the world. In fact, unless you are physically bringing in a person with a disability to test your site out, you really have no idea what sort of experience you’re offering. Installing screenreader software yourself isn’t really good enough because you’re not even close to a typical screenreader user. Even going so far as to put on a blindfold isn’t good enough because again, it’s just not your element; you’re going to be comparing everything to the visual world. Unless you’re willing to go a few months in a screenreader user’s shoes, your value as a tester is limited.<\/p>\n

The other really interesting takeaway from the study is that visually-impaired users reportedly don’t want a “text-only” version of the site to use… a sentiment I’ve heard before. Here are two quotes from the participants explaining their reasoning:<\/p>\n

“I never trust screenreader versions because the text version is never updated.”<\/p><\/blockquote>\n

“It’s double the work to do text and graphic versions. It’s better to make the graphic version accessible.”<\/p><\/blockquote>\n

With all due respect to the participants, I don’t buy either argument. The first reason cited is an execution problem and not a conceptual problem. If you are making a text-only version of your site for accessibility reasons and you’re not updating that content as often as the main version, you can’t even really call it a text-only version of the site anymore. It’s a partial shadow of your site, but it’s not a text-only facsimile of it. THAT, is what screenreader users resent… the lack of equal content. If we lived in a world where every site had a perfect text-only equivalent, which version do you think screenreader users would find more usable?<\/p>\n

The second reason cited (the “double-work” rationale) is also an execution issue to me. At ESPN.com, we run our wireless site pocket.espn.go.com<\/a> using the exact same data sources as our main site. With smart templating on the server-side, content can be served to our main site or our wireless site simultaneously with no extra effort. Since Pocket PCs and other handhelds have such limited support for XHTML\/CSS\/JS and all the other stuff we throw into graphical web browsers, it’s better to just not serve that stuff up in the first place. If you serve up a simple XHTML page instead with no extraneous elements, it takes a lot less CSS trickery (and a lot less bandwidth) to get where you need to be (more discussion on this subject is available in the comments of “Targeting Small Screens” over at Stopdesign<\/a>). So I guess my argument is that it is very<\/em> possible to have a simpler version of your site which doesn’t require double the work if you employ smart server-side templating.<\/p>\n

And that brings me to the final thought of this entry: Does the advent of mobile web browsing help us in the quest to provide more usable sites for disabled people? I think that it does. In a pretty significant way. As our sites are viewed by more mobile users, the “mobile” version of the site (which is pretty acceptable to have) becomes more and more important to us, and thus we begin to put even more time into it. We also can’t help but thoroughly test it because we become handheld users ourselves. At the point where we have parity, won’t the mobile version provide a better experience to screenreader users than the version filled with Flash, sponsorships, and extra code for traditional web browsers? I think that it will. Designing for handhelds forces<\/em> you to think like a screenreader user, and that’s a good thing.<\/p>\n

Now, I realize that the whole “separate version” issue is controversial and before anyone jumps on my case, I do think that extremely simple sites can get away with one version. It’s just that for more complicated sites, I feel like it’s a lot less work to “prep” for accessibility on the server side. If you do things correctly, all you’re doing is hiding and rearranging content server-side that you would have done client-side with CSS. How is this a bad thing?<\/p>\n

Thoughts?<\/p>\n

(By the way, I fully expect to get beaten down on this by some camps. I am not an expert and I’m just throwing this out there because it makes sense to me.)<\/p>\n","protected":false},"excerpt":{"rendered":"

If you think you knew how to design or code a site with disabled people in mind, head on over to this National Institute of Standards and Technology accessibility study (via: Henrik Olsen) and find out exactly how much you don’t know. Somewhere in Toronto, even Joe Clark is taking notes. In a nutshell, Redish & Associates observed 22 screenreader users interact with a variety of web sites…<\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[37,282],"tags":[],"class_list":["post-64","post","type-post","status-publish","format-standard","hentry","category-code","category-original"],"_links":{"self":[{"href":"https:\/\/mikeindustries.com\/blog\/wp-json\/wp\/v2\/posts\/64","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/mikeindustries.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mikeindustries.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mikeindustries.com\/blog\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/mikeindustries.com\/blog\/wp-json\/wp\/v2\/comments?post=64"}],"version-history":[{"count":0,"href":"https:\/\/mikeindustries.com\/blog\/wp-json\/wp\/v2\/posts\/64\/revisions"}],"wp:attachment":[{"href":"https:\/\/mikeindustries.com\/blog\/wp-json\/wp\/v2\/media?parent=64"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mikeindustries.com\/blog\/wp-json\/wp\/v2\/categories?post=64"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mikeindustries.com\/blog\/wp-json\/wp\/v2\/tags?post=64"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}