This is the fifth and last module of this MOOC. We've covered a variety of issues about making courses accessible and inclusive. But with just five weeks, our treatment of this topic is by no means comprehensive. We try to touch upon some key issues that often create obstacles for students with disabilities and if addressed can make a significant improvement in the inclusiveness of a course. In this last week's lessons, we will briefly cover some topics we have not covered, including keyboard accessibility, color contrast and the accessibility of learning management systems. We'll conclude this week's lessons with resources that will allow you to go further into creating inclusive courses for your students. Our assessment for this module will ask you to use these resources to research and propose solutions to situations that inhibit accessibility. Let's look now at keyboard accessibility, a topic we have covered only briefly. Keyboard accessibility means the ability to navigate and operate the controls of an application or web page using only the keyboard. Keyboard navigation is crucial for individuals who do not have the dexterity to use a mouse and for individuals who are blind. There is no tool or automated method for testing the keyboard accessibility of an application or web page. This is a test that needs to be conducted by hand. I'll add that automated tools such as achecker which we'll talk more about later can detect the use of JavaScript on a web page and warn you to check for problems, but it cannot determine if a particular page or script is keyboard accessible. Problems with keyboard accessibility are more likely to occur on websites that use JavaScript for creating controls and user input on a page. Problems are also more likely to occur with proprietary technologies, such as Flash or complex widgets such as media players. To check the keyboard accessibility of a web page or application, put your mouse to the side or disconnect it and use the keyboard to navigate and interact. First, try tabbing through the page on screen. On a web page, can access all the links, navigation and controls, such as form elements, search, for example? Is the page arranged logically for a keyboard user? In other words, do you progress through the page in a logical manner or do you jump from the top of the page to the bottom and then perhaps back to the middle? Is there a visually perceptual keyboard focus? In other words, can we tell our place on a page when we move through it using the tab? Web pages and applications that follow best practices present a clearly visible border or other visual cue, such as a change in foreground or background color, around or within the current object of focus. One of the better implementations of this is on the WebAIM site, which I am now showing. WebAIM is an organization that provides a wealth of resources around web and document accessibility. As I tab through the WebAIM home page, every link or control provides visual feedback as it receives keyboard focus. The clickable image at top left and the text space navigation on the right and the search field present a distinct new border as they receive keyboard focus. Some items display a red font upon focus providing additional visual feedback. Note that I can also enter text into the search field and tab search button and press Enter to initiate the search. Pressing Enter on any of the navigation elements or other links will also activate that link, the same as a mouse click. One particularly useful feature is a skip to main content link at the top left of a page, which is the first item that a keyboard user encounters. This link allows a user to jump past the branding and navigation element in the page directly to the main content. In this case, I am brought directly to the results for my previous search on the term keyboard. A keyboard user with vision should be able to easily determine their location on the page and interact with the links, and controls on the page. A blind user operating a screen reader would also be able to interact and navigate the page, although their feedback would provided by the screen reader audio and not visual feedback. Note that Mac OS users may need to turn on keyboard functionality in their browser through preferences within Safari or with Apple system preferences for Firefox. The link displayed here and also in the resource section of this module will point you to an article which provides step by step instructions on this issue. For an example from the other end of the accessibility spectrum, I'll display the homepage of The Daily Beast. As I tab through the page, I know I'm progressing through the page, because the status bar, bottom left is showing me changing URLs of the different links I'm landing on. However, I have no visual feedback that I am moving through the page. You can conduct this type of test yourself within any application or web page. If you could conduct only one test of accessibility, a test for keyboard accessibility might be the most revealing. That's because keyboard accessibility is required for both screenreader users and those unable to operate a mouse. A lack of keyboard accessibility indicates a fundamentally inaccessible page or application. In the next video, we'll talk about the last unaddressed issue on our agenda for this lesson. Poor color contrast.
