Download Avoiding the JavaScript:Void(``):

Avoiding the
JavaScript:Void(‘’):
Building Web Apps That Work
Anywhere and Everywhere
Jason Pitoniak
Rochester Institute of Technology
HighEdWeb 2008 ▪ TPR 4
October 6, 2008
What is the JavaScript Void?

The inability of a user to access web
content or features due to system
incompatibilities, such as the lck of
JavaScript.
<a href= “javascript:void('')” onclick=
“window.open('popup.html', 'height=500,
width=300);”>more information</a>
Accessible Content:
Not Just For Blind Users Anymore

The web is becoming increasingly
ubiquiteous:
 Mobile
Devices
 “Smart” Devices

Implications
 Smaller
Screens
 Lack of Graphics Support
 Lack of Scripting Support
Accessible Content:
Not Just For Blind Users Anymore

The web is being used by more lessexperienced users:
 Grandparents
 Disabled
Persons
 Lower Socioeconomic Status
Accessible Content:
Not Just For Blind Users Anymore

This means:
 Less
computer savvy
 Older, slower systems
 Possible assistive technologies
 Lower speed connections
 Less likely to do timely upgrades
Accessible Content:
Not Just For Blind Users Anymore

Some people just choose to be different:
 JavaScript
off
 Cookies off
 Styles off
 Using older or non-standard browsers
We’d Like to Accommodate
Everyone…But We Have a Deadline
Know your audience
 Code like it’s 1999
 Use progressive enhancement on the
client side
 Level the playing field with JavaScript
libraries
 Use WAI-ARIA to make it accessible

Code Like It’s 1999
As much as possible, return plain old
(X)HTML from server generated scripts
 Follow current standards to ensure
consistancy and forward compapatibility
 Make sure all basic functionality exists,
even if it ain’t pretty

Use Progressive Enhancement
There’s nothing wrong with bells and
whistles when they provide a benefit and
don’t confuse or hinder the user
 Use JavaScript to alter the page and add
the features

Progressive Enhancement
Examples
Forms and disabled fields: all fields should
be enabled by default and disabled with
JavaScript
 Calendar widgets: attach to date fields
after the page loads
 Popup windows: devise a method of
navigating to a new page and back

Level the Playing Field
JavaScript libraries, such as YUI and
jQuery:
 Eliminate many browser irregularities
 Add support for “missing” events such as
“onDocumentReady”
 Make it easy to work with AJAX and other
advanced features
 Offer clean, consistent sets of widgets
Progressive Enhancement 101
$(document).ready(function () {
$(“.datefield”).insertAfter(‘<input
type=“button” class=“calpopup”>’);
})
Use WAI-ARIA
ARIA attempts to solve the two biggest
issues regarding web accessibility:
 Runtime changes to content can’t be
“seen” by assistive technologies
 Users of don’t understand the intended
meaning of objects on the page
About ARIA
Accessible Rich Internet Applications suite
 Part of the W3C Web Accessibility
Initiative (WAI)
 A set of specifications for browser
manufactures and web developers to
follow to ensure the accessibility of web
applications

ARIA Roles and States

Operating systems generally define a set
of “atomic widgets” that are used in GUIs
 Fields,
labels, tabs, windows, etc.
ATs understand these widgets and
interpret them for the user
 The set of widgets available in HTML is
much smaller, so we fake them with
markup, JavaScript, and CSS

Example: Tabs
Typical tab list markup on a web page:
<ul class=“tablist”>
<li class=“selected”><a href=“#tab1”>
Tab 1</a></li>
<li><a href=“#tab2”>Tab 2</a></li>
…

Example: Tabs

What we see:
Example: Tabs

What the screen reader sees:
•
Tab 1
• Tab 2
• Tab 3
ARIA Roles
Attempt to tell the browser the indended
function of a piece of markup
 The browser should then pass that to the
AT
 Implemented using the “role” attribute

 <a
role=“checkbox”>…</a>
Recognized Roles



Role, Input, Textbox, Select, Range, Section, Sectionhead,
Window
Link, Combobox, Option, Checkbox, Checkboxtristate, Radio,
Radiogroup, Menuitemradio, Menuitemcheckbox,
Progressbar, Secret, Slider, Spinbutton, Separator, Textarea,
Textfield, Tree, Treegroup, Treeitem, Status, Alert,
Alertdialog, Dialog
Presentation, Appliction, Document, Group, Imagegroup,
Directory, Region, Liveregion, Log, Grid, Gridcell,
Tabcontainer, Tab, Tabpanel, Tablist, Table, TH, TD,
Rowheader, Columnheader, List, Listitem, Menu, Toolbar,
Menubar, Menuitem, Breadcrumbs
ARIA States

States define the current status of an
element
A
checkbox can be “checked” or “unchecked”
 A tab can be “selected”

States are implemented using aria-*
attributes
 <span
role=“checkbox” aria-checked=“true”>
ARIA States
Available states vary by role
 A few common ones:

 Checked
(true|false|mixed)
 Disbaled (true|false)
 Selected (true|false)
 Expanded (true|false)
 Valuenow, Valuemax, Valuemin
 Invalid (true|false) current value is invalid
Live Regions
Most ATs are unable to see that a page
element has changed if that element
doesn’t have the focus
 This poses a problem for most AJAX-type
RIAs
 ARIA Live Regions are designed to fix this

Live Regions
Live Regions are defined as sections of a
page that are likely to change
 Text in live regions can be spoken without
giving the region focus
 Live regions are denoted by the aria-live
property being set to one of the
recognized politeness settings

 <div
aria-live=“polite”>…</div>
Politeness
Polite - if content is currently being
spoken, wait until done before alerting of
change (default)
 Assertive – new content has a higher
priority than “polite” but still doesn’t
necessarilly interrupt the current content
 Rude – the new content has a very high
priority and the user should be notified of it
immeadiately

ARIA Downsides
Still in draft state and still evolving
 Not yet widely supported
 ARIA properties are not part of (X)HTML
specs and therefore do not validate

ARIA Is Not Enough
ARIA is designed as a notification tool only
 It does not help users interact with custom
widgets, navigate the page, etc.
 It is still necessary to include proper event
handlers on ARIA-enabled elements,
including keyboard navigation

ARIA and AAA





As you research ARIA you may come across
examples that use the aaa: namespace
Namespaces aren’t supported in HTML
Namespaces are only supported in XHTML
when the application/xhtml+xml MIME type is
used
IE doesn’t recognize application/xhtml+xml
So the namespace was dropped in favor of
the prefix aria- prefix instead.
ARIA Demos
FireVox Tutorials
http://firevox.clcworld.net/tutorial/tut4.html
 Mozilla Developer Center Examples
http://developer.mozilla.org/en/Accessible
_DHTML

ARIA Links




Intro:
http://www.w3.org/WAI/intro/aria
Overview:
http://www.w3.org/TR/wai-aria/
Roles Working Draft:
http://www.w3.org/TR/2006/WD-aria-role20060926/
States and Properties Working Draft:
http://www.w3.org/TR/2006/WD-aria-state20060926/
Toolkits
YUI Supports ARIA (with a bit of work),
YUIBlog articles frequently show how:
http://developer.yahoo.com/yui
http://yuiblog.com
 Fluid Project – a new, open source,
initiative built on top of JQuery
http://www.fluidproject.org

Screen Readers, Etc.
NVDA – Open Source Screen Reader
http://www.nvda-project.org/
 AccessFirefox – Accessibility Extensions
Overview Site (includes FireVox)
http://www.accessfirefox.org/

MobileOK

W3C Initiative for Designing for Mobile
Devices
 Working
Draft:
http://www.w3.org/TR/mobileOK/
 Basic Tests:
http://www.w3.org/TR/mobileOK-basic10tests/
 Validator: http://validator.w3.org/mobile/
I Am Accessible
Jason R. Pitoniak
Web Services Senior Programmer/Analyst
Information Technology Services
Rochester Institute of Technology
(585) 475-4186 ▪ [email protected]