Avoiding the JavaScript:Void : Building Web Apps That Work Anywhere and Everywhere - PowerPoint PPT Presentation

slide1 n.
Skip this Video
Loading SlideShow in 5 Seconds..
Avoiding the JavaScript:Void : Building Web Apps That Work Anywhere and Everywhere PowerPoint Presentation
Download Presentation
Avoiding the JavaScript:Void : Building Web Apps That Work Anywhere and Everywhere

play fullscreen
1 / 34
Download Presentation
Avoiding the JavaScript:Void : Building Web Apps That Work Anywhere and Everywhere
Download Presentation

Avoiding the JavaScript:Void : Building Web Apps That Work Anywhere and Everywhere

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

    1. 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

    3. 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

    4. Accessible Content: Not Just For Blind Users Anymore The web is being used by more less-experienced users: Grandparents Disabled Persons Lower Socioeconomic Status

    5. 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

    6. 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

    7. Wed Like to Accommodate EveryoneBut We Have a Deadline Know your audience Code like its 1999 Use progressive enhancement on the client side Level the playing field with JavaScript libraries Use WAI-ARIA to make it accessible

    8. Code Like Its 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 aint pretty

    9. Use Progressive Enhancement Theres nothing wrong with bells and whistles when they provide a benefit and dont confuse or hinder the user Use JavaScript to alter the page and add the features

    10. 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

    11. 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

    12. Progressive Enhancement 101 $(document).ready(function () { $(.datefield).insertAfter(<input type=button class=calpopup>); })

    13. Use WAI-ARIA ARIA attempts to solve the two biggest issues regarding web accessibility: Runtime changes to content cant be seen by assistive technologies Users of dont understand the intended meaning of objects on the page

    14. 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

    15. 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

    16. 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>

    17. Example: Tabs What we see:

    18. Example: Tabs What the screen reader sees: Tab 1 Tab 2 Tab 3

    19. 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>

    20. 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

    21. 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>

    22. 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

    23. Live Regions Most ATs are unable to see that a page element has changed if that element doesnt have the focus This poses a problem for most AJAX-type RIAs ARIA Live Regions are designed to fix this

    24. 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>

    25. 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 doesnt necessarilly interrupt the current content Rude the new content has a very high priority and the user should be notified of it immeadiately

    26. 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

    27. 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

    28. ARIA and AAA As you research ARIA you may come across examples that use the aaa: namespace Namespaces arent supported in HTML Namespaces are only supported in XHTML when the application/xhtml+xml MIME type is used IE doesnt recognize application/xhtml+xml So the namespace was dropped in favor of the prefix aria- prefix instead.

    29. ARIA Demos FireVox Tutorials http://firevox.clcworld.net/tutorial/tut4.html Mozilla Developer Center Examples http://developer.mozilla.org/en/Accessible_DHTML

    30. 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-role-20060926/ States and Properties Working Draft: http://www.w3.org/TR/2006/WD-aria-state-20060926/

    31. 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

    32. Screen Readers, Etc. NVDA Open Source Screen Reader http://www.nvda-project.org/ AccessFirefox Accessibility Extensions Overview Site (includes FireVox) http://www.accessfirefox.org/

    33. MobileOK W3C Initiative for Designing for Mobile Devices Working Draft: http://www.w3.org/TR/mobileOK/ Basic Tests: http://www.w3.org/TR/mobileOK-basic10-tests/ Validator: http://validator.w3.org/mobile/

    34. I Am Accessible Jason R. Pitoniak Web Services Senior Programmer/Analyst Information Technology Services Rochester Institute of Technology (585) 475-4186 ? jrpisd@rit.edu