Accessible Web 2.0 Applications PRESENTED BY: Arne Louison, Web Developer, Governor’s Office of Employee Relations Jeff Bennett, Programmer & Usability Tester, Office of the Chief Information Officer / Office for Technology Mike J. Hritcko, Web Developer, NYS Insurance Fund For the NYS FORUM IT ACCESSIBILITY COMMITTEE

Introductions Arne Louison Governor’s Office of Employee Relations Mike Hritcko State Insurance Fund Jeff Bennett Office of the Chief Information Officer / Office for Technology

Today’s Agenda Web 2.0 Web Accessibility AJAX ARIA

What is “Web 2.0”? Describes the trend in the use of web technology and design to enhance creativity, information sharing, and most notably collaboration among users through the use of interactive components.

Examples of Web 2.0 Social networking service – an online community of people that have similar interests or participate in similar activities. The interaction between these users takes place through the use of online chat, online messaging, video, voice chat or discussion groups…the list goes on.

Examples of Web 2.0 Wiki – a collaborative web site whose content can be edited by anyone who has access to it.

Examples of Web 2.0 Portal – a web site that functions as a collection/entry point for various resources on the site or through external forces (e.g., RSS feeds), and users expect current info at all times.

Examples of Web 2.0 Blog – a web page or site usually maintained by a single person with regular entries of commentary, descriptions of some events or other material. An example would be John Doe posting a few paragraphs on his web site about his ski trip to Aspen. *** (Some blogs permit comments by visitors)

Web 2.0 does not pertain to updates or changes to technical specifications for web languages; refers to changes in the way developers code and visitors user the web. Web 2.0 is not a recommendation by the W3C. Technologies involved in making Web 2.0 web sites such as JavaScript, CSS and HTML are not new, they have been around for a long time.

Screen Reader Demonstration Jeff Bennett, CIO/OFT. Inaccessible form example. Accessible form example. Inaccessible RSS Feed Accessible RSS Feed Discussion on how the screen reader transforms the page to the user.

What’s the difference? With proper semantic markup: ◦ Screen reader renders form properly ◦ User knows what info to provide on first try because programmer/developer properly codes input element By providing adequate user support and instructions, server traffic is reduced.

Web Accessibility What makes it so difficult to make a data driven, visually engaging page, portal, or even dashboard? Dashboard is an application, like a Portal, that provides one central location to get current, real time data. In other words, a “Dashboard” is a presentational format, a visual form of the Portal concept. The evils of buzzwords. Web 2.0 leans toward the latest and least proven technologies.

Portals A web site or web page that functions as a gateway for various resources. Yahoo’s home page would be a good example of a Portal, which is also customizable by any user as “My Yahoo” Usually includes a few “widgets” on a web page that link to or access other resources. These resources can be internal or external. A widget is defined as a chunk of reusable code that can be installed and executed within any separate HTML-based web page by an end user without requiring additional compilation.

Portals (cont’d) Some products that provide access to APIs to easily build these pages through a WYSIWYG editor. Can be made out of a single web page using server side includes: ColdFusion: PHP: ASP:

Example of a “Portal” using server-side includes

Is this Portal Accessible? Assume that all the pages were validated using the NYS Validation Tool. Assume they are compliant with the NYS Standards. So having this knowledge, would this example be accessible? Let’s discuss what makes a page accessible.

Certain things are required to make sure that a page is accessible. Proper semantic markup. Tabindex attributes where appropriate. So having this knowledge, is this web page, or “Portal” accessible? Without looking at the code there really is no way to tell.

I’ll answer the question for you, Sort of…. Okay, why? The page uses no other HTML markup other than DIV tags. This does not allow for proper semantic markup…….HUH????? By using, and other semantic tags, the screen reader has some frame of reference of what you are trying to accomplish. Example: 1 Home Page 9 Pages brought in by server side includes.

Example of a Portal shell

What I am trying to show here is that a page using only DIVs could be made to be accessible if you properly code the page. How is this done? Widget 1 Widget 2 Widget 3 Widget 4 Widget 5 Widget 6 Widget 7 Widget 8 Widget 9

Order is good By putting the DIVs in order of how you would like them to be presented, this page could be made to be accessible, and a screen reader would have no issue rendering the page properly.

Why is this? When a browser receives a web page back from the server, the screen reader will cache the page. The screen reader interacts with the cached page, not with the page in the browser window. If content changes in browser window without reloading page, screen reader won’t know about it.

Why not use tabindex attribute? The reason is that as soon as you add a tabindex attribute to a non-sanctioned form element, the page instantly becomes inaccessible. Form elements, anchors and objects are the only elements within the HTML 4.01 specification that can have a tabindex attribute. The page will not pass any validation, NYS or otherwise.

Did we just see Web 2.0? Nope. This is just a workaround to get our feet wet.

Key concepts of Web 2.0 User interacts with page and makes requests.

Key concepts for Web 2.0 Browser allows JavaScript to make changes to page content – without server reloading page.

Will screen reader user be able to effectively interact with page?

Why JavaScript? Why not some other language? Simply put, JavaScript is client-side scripting - meaning that the processing and changes are done on the client’s PC, within the browser session.

Why JavaScript? Other scripting languages, such as ASP, PHP, ColdFusion, etc. are considered server-side and a request has to be sent to the server for a change or response.

Server-Side Scripting A request has to be made to the server for a response, which in turn will refresh the page. Causes the page to be refreshed every time a new request is made because the page is returned from the server. This can cause excess server traffic. Not very efficient in high traffic sites and can dramatically effect the server’s performance.

Client-Side Scripting Once the page is rendered in the browser, the only requests that are sent to server, are from a “widget” on the page. Done by accessing the Document Object Model (DOM). Only refreshes the information in the calling widget.

The DOM Language and platform independent. Represents both HTML and XML. Suited for applications that need to access a document out of sequence. Required by JavaScript to modify a web page dynamically.

The DOM Tree structure. Parent-child relationships. Create elements ◦ document.createElement(“value") Navigate elements ◦ getElementsByID() ◦ getElementsByName() ◦ getElementsByTagName() ◦ getElementsByClassName()

With all this technology, where is the problem? We talked about how the screen reader caches the page when the browser first receives it. In current technology model, no way for the screen reader user to know anything has been updated or changed on the page. This is a HUGE problem for screen reader users, who find: - dead links - broken forms - wrong info – that appears right

AJAX (Asynchronous JavaScript and XML) Allows cool effects, such as: Adding form elements on the fly. Auto-Suggest features. Updatable Grids that mimic Spreadsheet applications. Uses current technologies such as HTML, JavaScript and CSS. XMLHTTPRequest() method

ARIA (Accessible Rich Internet Application) Not a W3C recommendation yet, it is a working draft. Goal: making AJAX-like applications accessible. Uses the Accessibility APIs of OS platforms to interact with Assistive Technologies. Accomplished using Roles, Properties, States, focus(), and good use of tab indexes.

Tabindexes?? Tabindex attribute has limited use in the current standard. (A, AREA, BUTTON, INPUT, OBJECT, SELECT, TEXTAREA) ARIA may expand usage and utility of the tabindex attribute.

Confused yet? ARIA is in its infancy and is not a recommendation yet. Browsers and Assistive Technology can’t fully implement until it is a recommendation.

Insight into ARIA But I would like to give you a little insight into what they are trying to accomplish with ARIA before we part ways today.

ARIA - Roles Roles – used to define a widget and what a widget will do.

ARIA - Properties and States Properties and States Examples: - aria-checked - aria-labelledby - aria-describedby - aria-haspopup - aria-expanded

focus() focus() - method to move keyboard focus to a DOM node using JavaScript.

tabindex Used for identifying elements that can receive keyboard focus.

Notice a trend? Keyboard focus and keyboard navigation.

Namespaces Make it possible for older browsers to make some use of ARIA markup. xmlns:wairole=“ xmlns:aaa=“

Checkboxes in ARIA Widget Checkbox 1 Widget Checkbox 2 Widget Checkbox 3

Research Research Research Resources: Accessibility Committee ◦ es/ es/ Resources from this presentation ◦ es/curriculum/scripting/index.html es/curriculum/scripting/index.html