Accessible Web 2.0 Applications

Download Report

Transcript Accessible Web 2.0 Applications

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:
<cfinclude template=“weather.html”>
PHP:
<?php include ‘weather.html’ ?>
ASP:
<!--#include file =“weather.html"-->
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 <h1>, <h2> 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?
<div id=“1”>Widget 1</div>
<div id=“2”>Widget 2</div>
<div id=“3”>Widget 3</div>
<div id=“4”>Widget 4</div>
<div id=“5”>Widget 5</div>
<div id=“6”>Widget 6</div>
<div id=“7”>Widget 7</div>
<div id=“8”>Widget 8</div>
<div id=“9”>Widget 9</div>
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=“http://www.w3.org/2005/01/wai-rdf/GUIRoleTaxonomy#”
xmlns:aaa=“http://www.w3.org/2005/07/aaa”
Checkboxes in ARIA
<ul class="checkboxes">
<li tabindex="0" role="wairole:checkbox" aaa:checked="false“
onclick="handleClickCheckbox(event)" onkeydown="handleKeyDownCheckbox(event)">
Widget Checkbox 1
</li>
<li tabindex="0" role="wairole:checkbox" aaa:checked="true"
onclick="handleClickCheckbox(event)" onkeydown="handleKeyDownCheckbox(event)">
Widget Checkbox 2
</li>
<li tabindex="0" role="wairole:checkbox" aaa:checked="false"
onclick="handleClickCheckbox(event)" onkeydown="handleKeyDownCheckbox(event)">
Widget Checkbox 3
</li>
</ul>
Research Research Research
Resources:
 Accessibility Committee
◦ http://www.nysforum.org/accessibility/resourc
es/

Resources from this presentation
◦ http://www.nysforum.org/accessibility/resourc
es/curriculum/scripting/index.html