The audio for this podcast can be downloaded at http://highedweb.org/2008/presentations/tpr4.mp3
[Intro Music]
Announcer: You're listening to one in a series of presentations with 2008 HighEdWeb Conference at Springfield, Missouri.
Jason Pitoniak: Hey! Welcome. I am Jason Pitoniak. You figured that out already. I work for Rochester Institute of Technology. Up until exactly one month ago today, I worked for one of our colleges which is the National Technical Institute for the Deaf. So I think that’s kind of – this speaker right behind me is kind of annoying.
I think that’s kind of what got me into the whole accessibility thing. I’m really more of a backhand programmer, but because I was in a position where I was developing materials. Basically instructors would come to us and say, “This is what I want to present. How can we make this work for a deaf audience?”
It’s a different type of accessibility than what I’m going to be talking about today, but that sort of accessibility thing in general I think working in that environment kind of got me into that mind set. What is the JavaScript void? Well, this term that I coined for this conference last year. It’s the inability of a user to access Web content or features due to system inability such as the lack of JavaScript.
The name comes from this link that I’m sure many of you have used and I know I’ve used it in the past. The problem with it being that if you don’t have JavaScript enable in your browser or you're using something that doesn’t support, you start clicking on that link it does absolutely nothing and it’s not very useful. I’ve seen entire websites that are built using links like that. They are completely inaccessible.
I can take the whole accessibility thing from a general perspective. It’s not necessarily most people say that it’s designed for blind users as well. There’s more to it than that. I just said you know deaf users which is different but still something to consider. Lana is I’m sure going to do an excellent presentation on that aspect of thing so luckily I don’t prepare that.
The Web as everyone here knows is becoming more and more ubiquitous. We’re seeing it on mobile devices. We’re seeing smart devices like $900.00 coffee pots that have plugs in them and things like that. So the implications of that, we’ve got smaller screens that we’re dealing with, lack of graphical support sometimes, lack of scripting support quite often.
I used in my old job. I had a PDA that didn’t have a JavaScript on it. Few of the websites that I went to use from there I just couldn’t. It’s also being used by less experienced users, so we can’t really rely on our users knowing what to do all the time. Something doesn’t work right. They expect it’s going to work right away.
I gave a computer to my grandmother. There’s a mouse here. The computer that I used all through college, when I got out of college, I bought a better computer. I gave my grandmother my old computer. She took the mouse and having it on the desk like this and she held it like this and tried moving it around and then went to click, of course, moved it out off the button that she’s trying to as kind of interesting.
Disabled persons, the Web gives a lot of people an opportunity to interact. Because of their disabilities, they couldn’t do in the past maybe. They can get out and talk to people. They might be homebound, but they can get out virtually and talk to more people and interact with more people that way.
Because computers are getting so cheap, I just bought a really nice brand new system for $500.00. It’s the Core 2 and Dual Core and tons of memory and all that. That was $500.00. Anyone can pretty much afford pretty high-end computer stuff.
So this means, we’ve got users that are less computer savvy. They’re possibly using all their hand-me-down systems like the one that my grandmother has which she still have even though it’s now close to 15 years old. We’ve got to take into account the assistive technologies: screen readers, the Braille devices, like Jeffrey just had in his presentation, magnifiers, and all those kinds of things are come into play.
We also have to think about those speed connections which is always been an issue, but now we’re getting into the YouTube generation there. Everyone is expecting high-speed streaming and all that, but you might still get especially if you're talking Intel and some things like that. You still have that bandwidth thing that you take into consideration.
Some of these users are probably less likely to do timely upgrades to their softwares. They’re going to be using the older browsers. I don’t know what more to say about that. There’s the group of people and some of you maybe in this room that just choose for whatever reason to not have your JavaScript turned on or not have cookies enabled, style sheets off or whatever reasons you might have. There’s that group to take into consideration as well and then, the older browsers again that Netscape 4.
Actually, I remember I think it was Windows 95 for a while. I think it had three years something like that. For a while, the Microsoft Website was completely inaccessible with that version of the browser. So if you re-install Windows, you had to actually go and download Netscape in order to upgrade IE.
We want to accommodate everyone. [Laughter] I want to move over on this side now far, far away from the speaker. We’d like to accommodate everyone. How can we do that in a manageable way?
Well, first of all, you have to know your audience. If you're doing a public facing website, you do have to take a lot of things into consideration. A lot of them you probably want to take into consideration on a regular basis anyway. Things like the accessibility for blind users and things like that because you never know when you're going to have someone even if it’s an internal app. You’ll never know when you're going to hire someone that’s going to have vision impairment or something like that. It’s going to rely on that.
Code like its 1999, I’ll explain that in a minute, but it’s a term that I came up with again last year when I did a similar presentation. Once you’ve coded like its 1999, you use progressive enhancement on the client side to bring it up to 2008. Use JavaScript libraries to do that. They make it really easy in a lot of cases.
And then, finally, the web accessibility initiatives area which brings in a lot of tools for better accessibility another thing to consider in the end or not. It’s kind of all goes together.
So its code like 1999, you know things are getting ahead of you there, but as much as possible just return plain old HTML. It’s not always going to work out for you like I’ve got a couple of examples later that are kind of difficult to solve but if you can return it in plain old HTML, you know it’s going to work anywhere.
Follow the current standards get away from 1999 there probably should, so you can ensure that it will be compatible going forward. Make sure all of your basic functionality is there from the beginning. That way anyone that goes into that site no matter what type of device they’re using, no matter how old their software is, whatever they’re going to get something that works and then you use progressive enhancement on it.
Once you’ve figure out that they have JavaScript support which is just basically the JavaScript runs, you can add the bells and whistles in. Basically, just use JavaScript to alter it. If you do it in a way that it gets altered before it gets presented to the user then anything, any assistive device, anything like that will see the altered page first. They won’t know that anything changed.
So some examples of progressive enhancement, forms, sometimes it’s common to have liked a checkbox. Someone will check the box. All these fields become enabled. Well, if you don’t have JavaScript you can t do that, so that form then becomes accessible to anyone that doesn’t have JavaScript support. You put them all enable to begin with. Use your server side to filter out however you need to. Then, when it gets to the client side, you can disable them.
Most people will use it as expected. Some people if they don’t have the JavaScript support partly can still submit it. They might submit things that shouldn’t be there. What happened? You can figure that out in the server and accommodate that.
Calendar widgets, all seem them where you have a date filled, you click button, a little calendar pops up. It may or may not be depending on your users. An issue but again if you don’t have JavaScript they could click on that button all day, depending maybe a screen reader or something like that since they say that’s the button and they might sit there, trying to submit with that button or something they won’t work. Just, you know, something to consider.
This is the one that’s difficult when you have like one of the select box that says, “Choose an option,” and then, there’s the link next to it that says, “Add another option,” and then, you click it and it opens up a pop-up window. The only way that I’ve really could see getting around of that would be have some way of going to another page, entering information and coming back to where you were and having the same states. That’s the difficult one to solve.
I’ve played with some things, but I haven’t come up with good way to solve that one yet. It goes back to knowing your users and accommodating as best you can. Sometimes some things just might not pass well but know how important it is.
JavaScript libraries, the two that I used most often are the Yahoo User Interface and jQuery. I like the fact that jQuery is chainable. You can do lots of things about doing a lot of work. YUI, I keep going back to because they’ve got the best widgets that I’ve seen, the consistency of them, and the options that come with them, but you’ve go to use this big long namespace functions and do a lot of typing with YUI. So I prefer jQuery when I can, but when I start getting to calendar widgets and auto complete and stuffs like that I tend to keep going back to YUI.
All of the major libraries that are popular right now, they eliminate any irregularities between your browsers, so you don’t have to worry about the event model being different in one browser and another. They’ve compensate for that behind the scenes. You just rate one function and you're done.
They also add support for missing events like the one that they all do is some version of undocument ready jQuery ready. Different libraries have different terms. However, it’s just basically a way of getting content into the page before it actually gets rendered in the browser so that way you can go and you can make all these changes to your page. The user doesn’t know that that’s not what just came down from the server necessarily.
They also just make it easy to work with Ajax. Again, that’s a situation where the XML, GTP request project is different in every browser. These just kind of standardize half ways. Those are the big reasons I see for using the JavaScript libraries. Things like YUI and jQuery that they are working on it. The jQuery UIs is coming along pretty nicely, the widgets which give you that Web 2.0 feel to your applications.
This is just an example. It’s jQuery code of that progressive enhancement. What you're actually doing in this case the document ready. Let’s just say, Windows documents are ready to be presented to the user, go and then do this. In this case, I’m just adding a button at the end of another, whatever, and anything that has a date field class is – I’m just inserting another button after it. That would be the little pop-up calendar thing pretty straight forward.
We get into ARIA. ARIAs are designed. Well, I have a slide on that. It attempts to solve the two biggest issues relating accessibility and that is one run time changes like anything that gets updated because of changes that you make locally like when you check boxes and new section of the page appear with new options or whatever. Those were able to be seen by the assistive technologies.
Users that might assistive technologies disappeared from there, but they generally don’t understand even if you use the best semantic markup. They’re still not going to see exactly what you intend for them to see. So area helps do that as well.
ARIA stands for Accessible Rich Internet Applications. It’s a suite which is part of the Web accessibility initiative from the W3C. It’s basically it’s a set of specifications for both present manufacturers to follow and for developers to follow to make them play together. They just help ensure accessibility to users of these assistive technologies.
The two big areas of ARIA are the roles and states. Basically, operating systems generally define what ARIA defines as atomic widgets. There are things like your form fields, labels, windows, tabs, and all that sort of stuff that the users are interacting with.
In an operating system, that’s just part of the OS there. So when a user clicks on it or tabs into a field of tabs if they are using keyboard, it’s going to tell them, “You’ve just landed on a tab” whereas, if you do markup in a browser they’re not going to get back because there is no concept of a tab in a browser.
The assistive technologies understand the widgets and interpret them, the browser widgets like they just know what they are because they are there. They are part of the OS. Then, like I said the HTML it’s a much smaller set of what’s there. We’ve got form fields and buttons and links and things like that but they’re aware of what most of the other things. We just kind of fake it to make it look the same as the OS.
But to an assistive technology, it’s a little different. For example, here are tabs. That’s kind of the general markup that we might use to do a row tabs on a Web page. It’s using an ordered list but with some CSS and JavaScript, you end up with something that looks like that.
But to the screen reader that’s reading over that, they see it basically as plain old HTML. They’re going to read list item tab one, list item tab two. So ARIA roles basically attempt to tell the browser that this markup here is a set of tabs that the UL is really a set of tabs and each LI in there is an actual tab. Then, the browser should be able to pass that to the assistive technology.
Basically, it’s just implemented by adding the role attribute to any of your HTML markup. In this case, it would be a link but styled to look like a checkbox or something like that. So you give it a role of checkbox.
These are the roles that are defined in the current stock from W3C. Study that carefully. There’s a test at the end. [Laughter] But just basically, there’s a whole bunch of stuff there. A lot of them are ready defined in HTML. Things like down button here, we’ve got table, table head, and table data.
There’s field. I don’t see it on here now, a text area right there, text fields over here. There are things that are already there, but sometimes you want to implement something that’s done a little differently like a checkbox. You might want to have better styling on it. Then, what you get is just the typical a little checkmark, so you do it as an image. I’m sure you’ve all seen that done many times. So with ARIA, you can actually say, “I’m using an image but really it’s a checkbox.”
Then states of the next component of ARIA and basically, they defined the current state of an object. It will vary depending on what role you’ve given the object, but these things like a checkbox could be checked around checks. A tab can be the selected tab out of a set of tabs.
They are implemented using the ARIA-state and whatever the list. In this case, for the checkbox will be ARIA-check and then it’s a boolean value. So it would be a true or false depending on what the role or what state is. You have multiple possibilities, different values available. There’s a whole bunch of states. I didn’t bother to make a slide of all of them. They do very value which role you're in.
Here’s a field of common things checks, disabled, selected. If you're doing like a slider kind of control or some sort of thing with the range of values, you might have the value now and then minimum and maximum values that define that slider. Then, there’s an invalid state.
So if you have a slider that can select anything from 1 to 10 and currently has the value of 11 somehow set in it. Then, it can be marked as being invalid. That would just discourage your form if you try to submit the form. It would be able to trigger that system adapted. If isn't a valid value in here right now, so they sort of error state.
Then, the next component – there’s actually more to ARIA than just role states and live regions that I’m going to cover but these are kind of the big ones. Live regions, as you probably know most assistive technologies aren’t able to interpret that something has changed in the page unless it has the current focus.
If you land on a text field let’s say in and some JavaScript you just change that value and you’ll see that changed, but if you have like Ajax delivering new content to the page you’ll probably not going to see that something changed up in the page somewhere. So the live regions basically are designed to address that.
The actual definition of a live region is just a section of a page, it’s like the change. That’s exactly what is says right of the W3C spec. Text and live regions can be spoken without getting the focus where most of things in order to be spoken by a screen reader have to get the focus.
Live regions have a mechanism there that should notify the operating system and into the assistive technology that this region has changed and depending on the importance that you set which is part of the live property that you would set the state technically depending on how you set that. There’s four different values actually but based on that would trigger when that notification goes out to the user.
The politeness as they call it is the values for that state. There’s none which is the default. There wouldn’t be any notification that something has changed that it’s set to none. And then, there’s polite assertive and rude. Polite is what you would generally use. It waits until say you're reading a block of text. It would go and wait until all of those texts are read before it notified that there’s a change.
Assertive is it doesn’t interrupt right away, but has a higher priority than polite, so it might be something like there’s no real clear definition on this at this point that I’ve seen. But it would say something like maybe you get to the end of the paragraph and then it would notify you rather than just interrupting in that sentence or whatever. Then, rude is just for really important kinds of updates. The nuclear reactor is about to blow up. You need to know this right now, so that would be rude.
ARIA does have it down sides. It’s still in draft stage. It’s still evolving. What I just showed they actually did just recently change quite a bit. It could very well change again before any publish status comes along. It’s not very widely supported. I’ve heard rumors that Safari is now supported, but the only one that I know that really supports it is Firefox 3 at this point.
The properties aren’t part of XHTML or HTML, so if you have them in your markup, your page isn't going to validate. It’s not the beyond and all the accessibility. It’s designed just as notification tool. So it doesn’t allow the users to interact with any of your markup or anything like that. You still have to do all that with JavaScript.
It’s really just there to describe that something has changed or that something has an alternate use of what it really looks like its set to be doing. It still is necessary to do all your event handlers. The big one I point out here is keyboard navigation because I know, for me at least, I tend not to think about keyboard navigation when I’m designing something and hover on there and have something pop-up.
I don’t often really consciously think about keyboard navigation when I design something, so that’s still very important. You're not going to achieve any sort of accessibility even if you use all of these, your roles and states unless you do cater to that.
One thing you might see when if you start looking for documentation in ARIA is references to an AAA namespace. AAA represents the original name that was given to ARIA. I don’t remember what that is, but it was namespace. You have to actually use an xmlns in your XHTML with the URL. All of the roles are all the properties that have to do with ARIA where AAA colon something.
Well, that poses a problem because first of all, there’s no support for namespaces in normal HTML. There was kind of a work around they came up with using plus names and stuff like that, but it was kind of convoluted.
The only way that namespaces are supported other than the HTML namespace I guess whatever the default one is. In XHTML is that you send the application/HTML plus XML header and Internet Explorer doesn’t recognize that, so it doesn’t treat pages a normal HTML page if you use that header, so that kind of makes it a little difficult to implement.
The use of the namespace was recently dropped in the latest draft. I’m not sure exactly when that came out, but they went for the ARIA prefix. And then for roles, they just went with role rather than trying to commit. It's not ARIA role just role. So they went with that instead.
So it's open to demos out there. Problem with them is if you don’t have a speech reader, a screen reader you kind of stuck. You can implement it and kind of hope that it works. That’s the problem with the lot of accessibility stuff because if you don’t have the assistive technologies you don’t necessarily know that it works.
There’s a browser called screen reader called NVDA. It stands for NonVisual Desktop Access. It’s an open source project. I think it’s in alpha stage right now. I do have a link to it later in the presentation if you want to check it out.
I was trying to get that to work as it supposedly does support all those stuff but for whatever reason when I ran it and I opened Firefox in Vista which I have in this laptop, it crashed Firefox. Then, I went and I installed a Windows XP virtual machine, I get it running in that, but then it freezes all the time.
I ended up finding that there’s what they call Fire Vox, so plugin for Firefox that basically turns Firefox into a screen reader. I can show these demos. They’re kind a neat.
Actually I need to enable Fire Vox first before I can do anything.
This is as close it is. It is really annoying when your browser starts talking to you when you're trying to check your email and things like that.
[Laughter]
I should restart this again although this has been really annoying and slow today.
If you do CTRL plus SHIFT plus A, I don’t know if you heard that but it will actually start reading the page. For whatever, I always open the view source view maybe.
Ok.
Hopefully, we’ll have better luck on the actual demos. This is basically just a little square board kind of thing. As you can see, as it speaks things are changing. It also highlights them in black.
I’d rather sit here and dot that for a while. I don’t know how well you can carry any of that. Mozilla developed her center actually has some pretty neat tutorials using some of the roles and states stuffs.
Screen Reader: Checkbox.
Jason Pitoniak: This one is an example of using roles and states. I’ll show you the markup first with the page.
Screen Reader: Select. Save page as.
Jason Pitoniak: You just…
Screen Reader: New page resource.
Jason Pitoniak: That’s a JavaScript. Alright. Then, you can see here the checkbox is implemented.
[Laughter]
Alright. That’s what I get for hitting the wrong button.
Screen Reader: New page source.
Jason Pitoniak: Alright, good. It went back where I want it. [Laughter] The checkbox is implemented as a span. You can see the area checked. The property is set by default to be checked. It’s given a tab index so that it can actually receive, focus as someone tabs through the page with the keyboard.
Then, there are also events for key down and click and then in there, there’s – my pointer seems to be failing on me. But in there, there’s the image source which is the actual checkbox button. It has a role of presentation. I’m not really familiar what that does. I think that just kind of says that this is presentation element. It’s part of the presentation of this group.
That’s essentially it.
So as I start tabbing through the page, it should announce, maybe…
Screen Reader: I’m going to check box. Check.
Jason Pitoniak: They’ll tell me that.
Screen Reader: I’m going to check box.
Jason Pitoniak: It’s telling me it’s a checkbox. I can actually – should maybe because that is required.
Screen Reader: Random emailing. Location box, http://inquiry/messaging... Check.
Jason Pitoniak: So I can uncheck it with the keyboard.
Screen Reader: Invalid checkbox. Check.
Jason Pitoniak: That’s basically that.
Screen Reader: Checkbox.
Jason Pitoniak: There’s all bunch of them on that page once you go to that website and download the presentation. You can play with those as much as you’d like. I just have a bunch of links in here. Basically, stuff for ARIA, the intro just log information on that site, and then the actual working draft overview and then the ones on roles and states I put up there.
Toolkits, YUI, doesn’t at least last time I looked, doesn’t natively support ARIA but if you go to the YUI blog they often post log entries on there that show how to add it into some of their controls. If you're looking to add it, it’s a good place to look.
And then, there’s this FLUID Project. I don’t know if there’s anyone here that is familiar with it at all. It’s an open source initiative. I haven’t played it too much yet, but it looks like it was built on top of jQuery. It’s basically just a tool for adding all these JavaScript widgets that are already ARIA compliant.
You might want to check that out. Then, I have links for NVDA browser. I just spoke about and access FireFiles. There’s a whole bunch of accessibility extensions for Firefox in there including Fire Vox which you just heard.
Mobile locate is another. I didn’t cover mobile at all in this presentation but just in the theme of general accessibility. Mobile locate is another W3C initiative that is designed around mobile devices and small screens and all those sort of issues. There’s some information on that, if you want to look into it.
Finally, IM accessible. I don’t have business cards, so that’s basically all that. I do but there are all – so it’s basically my information if you want to contact me I’d be happy answering questions or anything like that that you have.
I think we actually have probably about 3 minutes left so if you have any questions now. I’d be happy to answer them. Yes.
Male Audience: You say that YUI supports with a bit of work. Does that mean in Yahoo's part or on your part?
Jason Pitoniak: I’m the part of the developer although Yahoo has done a lot of it for you in the blog. They show you what you need to do, but it’s not just not natively there. You actually have to go in and change some things a little bit, not their code but just the way that you implement things. You have to have a couple of properties here and there and things like that.
It’s fairly straightforward. They keep adding. There’s like four or five of their widgets. They’ve done an article on how to do it now. So you could take a look and find that information. Yes.
Audience: Is it possible to have this supported in IE?
Pretty much from what I know, the whole ARIA support isn't there in IE. Supposedly, they’re working on it. I don’t know when they’re going to release anything. I honestly didn’t really go to look, but I don’t think what most of that supported in IE.
Male Audience 2: I’ve read that IE8 is listed with ARIA support.
Jason Pitoniak: Yeah, probably. I would say probably if they’re going to implement it. It would be in the next major version. Yes.
Male Audience 3: So you know about the state of support of Java?
Jason Pitoniak: I believe Java does support it. I think most of the common ones do. It’s a varying degree and actually with the YUI. They actually have some work around in there. The screen reader supports this way and this one you have to do this so just to add to everything that we have to do with three or four major browsers out there.
Now, we have to think about two or three screen readers on top of that.
Moderator: Anymore questions? Well, thank you, Jason.
Jason Pitoniak: Thank you.
[Applause]
For more presentations for 2008 HighEdWeb Conference visit highedweb.org/2008 or signup for our podcast feed at highedweb.org/podcast.xml.