1. Building Accessible Web Applications Antranig Basman, Fluid Core Framework Architect with Fluid Infusion

2. Fluid... Is an open source community of – Designers – Developers – Accessibility experts Helps other open communities Consists of universities, museums and individuals http://fluidproject.org

3. What We Do Code (examples, tools, best- practices) Design (advice, tools) Expertise & Resources Teaching & Evangelism Help

4. Tangibles core product: framework, code, components project with museums: visitor experience project with museums: collections management

5. Introducing http://fluidproject.org/products/infusion/

6. World, Meet Infusion Application framework built on top of jQuery The culmination of our work helping others Designed for usability and accessibility Open architecture: everything is configurable

7. What’s in Infusion? A development framework for building apps UI components you can reuse and adapt Lightweight CSS framework for styling Accessibility tools and plugins for jQuery

8. Building Great UIs is Hard Your code gets unruly as it grows UIs are hard to reuse or repurpose Design change requires big code change Accessibility is confusing Combining different code/libraries doesn’t always work

9. Flexible User Interfaces Infusion is an application framework designed to provide unprecedented flexibility while preserving interoperability.

10. Types of JavaScript Tools Foundational Toolkits Application Frameworks... compare and contrast

11. Foundational toolkits Totally presentation focused DOM manipulation Event binding Ajax jQuery Prototype Dojo core

12. Application frameworks Model notifications “something changed here” Views to help keep your presentational code clean Data binding to sync the display with your model SproutCore Dojo/Dijit/Dojox Cappuccino

13. Infusion is Different Accessibility baked right in Carefully designed interactions Markup is in your control Not the same old MVC Supports portals, mashups and CMS’s

14. Deeply Accessible

15. What is Accessibility?

16. A New Definition Accessibility is the ability of the system to accommodate the needs of the user Disability is the mismatch between the user and the interface provided We all experience disability Accessible software = better software

17. Assistive Technologies Present and control the user interface in different ways Not just screen readers! Use built-in operating system APIs to understand the user interface Screen readers Screen magnifiers On-screen keyboards

18. DHTML: A New Can of Worms Shift from documents to applications Familiar a11y techniques aren’t enough Most DHTML is completely inaccessible New techniques are still being figured out

19. The Problem Custom widgets often look, but don’t act, like their counterparts on the desktop HTML provides only simple semantics Not enough information for ATs Dynamic updates require new design strategies to be accessible

20. The Solution Describe user interfaces with ARIA Add consistent keyboard controls Provide flexible styling and presentation

21. Supporting Assistive Technology

22. Opaque Markup // These are tabs. How would you know? Cats Dogs Gators Cats meow. Dogs bark. Gators bite.

23. Opaque Markup: Tabs

24. ARIA Accessible Rich Internet Applications W3C specification in the works Fills the semantic gaps in HTML Roles, states, and properties Live regions

25. Roles, States, Properties Roles describe widgets not present in HTML 4 – slider, menubar, tab, dialog Properties describe characteristics: – draggable, hasPopup, required States describe what’s happening: – busy, disabled, selected, hidden

26. Using ARIA // Now *these* are Tabs! Cats Dogs Gators Cats meow. Dogs bark. Gators bite.

27. Adding ARIA in Code // Identify the container as a list of tabs. tabContainer.attr("role", "tablist"); // Give each tab the "tab" role. tabs.attr("role", "tab"); // Give each panel the appropriate role, panels.attr("role", "tabpanel"); panels.each(function (idx, panel) { var tabForPanel = that.tabs.eq(idx); // Relate the panel to the tab that labels it. $(panel).attr("aria-labelledby", tabForPanel[0].id); });

28. Keyboard Accessibility

29. Keyboard Navigation Everything that works with the mouse should work with the keyboard... but not always in the same way Support familiar conventions http://dev.aol.com/dhtml_style_guide

30. Keyboard Conventions Tab key focuses the control or widget Arrow keys select an item Enter or Spacebar activate an item Tab is handled by the browser. For the rest, you need to write code. A lot of code.

31. Keyboard a11y: Tabs

32. Tabindex examples Cats Dogs Alligators

33. Making Things Tabbable // Make the tablist accessible with the Tab key. tabContainer.attr("tabindex", "0"); // And take the anchors out of the Tab order. $(“a”, tabs).attr("tabindex", "-1"); Tabindex varies subtly across browsers jQuery.attr() normalizes it as of jQuery 1.3 - jQuery.prop() more appropriate as of 1.6 For all the gory details: http://fluidproject.org/blog/2008/01/09/ getting-setting-and-removing-tabindex-values-with-javascript/

34. Adding the Arrow Keys // Make each tab accessible with the left and right arrow keys. tabContainer.fluid("selectable", { selectableSelector: that.options.selectors.tabs, direction: fluid.a11y.orientation.HORIZONTAL, onSelect: function (tab) { $(tab).addClass(that.options.styles.highlighted); }, onUnselect: function (tab) { $(tab).removeClass(that.options.styles.highlighted); } });

35. Making Them Activatable // Make each tab activatable with Spacebar and Enter. tabs.fluid("activatable", function (evt) { // Your handler code here. Maybe the same as.click()? });

36. Documentation Tutorial: – http://wiki.fluidproject.org/display/fluid/Keyboard+Accessibility+Tutorial http://wiki.fluidproject.org/display/fluid/Keyboard+Accessibility+Tutorial API Reference: – http://wiki.fluidproject.org/display/fluid/Keyboard+Accessibility+Plugin+API http://wiki.fluidproject.org/display/fluid/Keyboard+Accessibility+Plugin+API

37. Infusion Goes Deeper jQuery Keyboard Navigation Plugin ARIA everywhere Everything is highly adaptable and flexible UI Options and the Fluid Skinning System: – Users can customize their environment

38. UI Options One size doesn’t fit all Allows users to customize your app: – layout – styling – navigation Uses FSS by default; can be configured to work with your own classes

39. UI Options & FSS

41. Fluid Skinning System FSS is built to be hacked on Provides a core set of building blocks Reset, text, layouts, themes Namespaced: no conflicts with your stuff Themes for better legibility & readability http://wiki.fluidproject.org/x/96M7

42. Building with FSS

43. FSS Themes Slate Mist High Contrast

44. FSS: Desktop

45. mFSS Themes iPhone Android

46. mFSS: iPhone Theme

47. mFSS: Android Theme <link type="text/css" rel="stylesheet" href="fss-mobile-theme-android.css" />

48. FSS: Tabs Go Back Go Back Go Back

49. mFSS: Back Button Back Button

50. FSS: Lists Link Text Link Text Link Text

51. mFSS: Image Grids

52. FSS: Widgets More Close Settings Regular Widget Option 1 Option 2 this is where the content goes

53. Open Architecture

54. Markup Agnosticism HTML is so fundamental to Web UIs Others lock away markup in a black box Markup should be totally free to edit, adapt, or replace Libraries shouldn’t bake in assumptions about your markup Unobtrusiveness everywhere

55. Handling Markup: Dojo x

56. Handling Markup: jQuery UI

57. Handling Markup: Infusion fluid.defaults("fluid.fileQueueView", { selectors: { fileRows: ".flc-uploader-file", fileName: ".flc-uploader-file-name", fileSize: ".flc-uploader-file-size", fileIconBtn: ".flc-uploader-file-action", errorText: ".flc-uploader-file-error" },

58. Components Infusion components aren’t black boxes Fundamentally adaptable: – Change the markup – Restyle with CSS – Add/replace actual behaviour Everything is super-loosely coupled “Components suck. Apps built with components look like it”

59. Component Families: Reorderer Infusion components come in families lists imageslayouts

60. More Components Uploader Pager Inline Edit

61. Model, View... but not Controller MVC is a given in most framework JavaScript’s functional idioms offer alternatives (hint: events) Infusion has no controller layer at all... and none of the classical inheritance cruft that usually goes with it

62. Traditional MVC

63. The Problem with Controllers Controllers are the least defined What’s “glue?” Always referred to as the non-reusable part MVC has been warped over the decades The framework should take care of the glue

64. Infusion Models & Views Controller is replaced by events Reads to the model are transparent State changes and notification are just events Transparent architecture: you can use the same events we use

65. Plain Old Models M is the most important thing in your app Data needs to travel seamlessly between client and server Most toolkits force a model to extend some base class or particular structure In Infusion, models are just plain old JSON

66. Playing Nice With Others

67. Portals, Mashups, and CMSs These days, diverse code and markup coexists Most JavaScript is written as if it owns the whole browser As you combine stuff, things can break Namespacing and privacy is essential

68. Writing Collision-Free JavaScript Put code in a unique namespace Use closures for privacy Support more than one on the page – Scope all variables to an instance – Avoid hard-baking ID selectors Constrain selectors within a specific element

69. Keeping it to Ourselves Infusion takes namespacing seriously We won’t steal your names Components are carefully scoped We won’t accidently grab the wrong stuff Infusion doesn’t expect control of the page

70. Tying it All Together Infusion helps you with accessibility Components you can really work with Simple structure so your code can grow Totally transparent, event-driven design Markup and models are under your control No inheritance or controller cruft

71. Where We’re Going

72. Infusion This Week Infusion 1.4 coming in June: New universal Inversion of Control system Improved UIOptions component Progressively Enhanced Uploader Lots of bug fixes Will be built into uPortal 4

73. The need for IoC Inspired by familiar frameworks on the Java-side such as – Spring, Google Guice Goes much further than these frameworks

74. The problem of software Failure of composability — combining modules A and B creates a system with greater than linear increase in complexity Failure of flexibility — addressing tasks X and Y involves more work than the union of the factored pieces of X and Y

75. The problem of software Failure of composability complexity(A + B) > complexity(A) + complexity(B) Failure of flexibility cost (X + Y) > cost(X) + cost(Y)

76. Your Future C = F + Ax γ (Feel free to stare at the ceiling) Development Costs Costs of Framework & Tools Functionality delivered to users γ > 1: Ball of mud, junkheap, death γ = 1: Scale-free development, endless life, “Code utopia”

77. This is your app

78. JavaScript is a GREAT environment Unexpectedly, for solving these highest- scale engineering problems JSON is a superb dialect for expressing – a general model for state – representation of structures like syntax trees

79. Elements of the solution IoC system with some concepts inherited from Java world, but much cooler – A “context” is any element of the tree being constructed – Entire tree is addressible using context + path expression syntax – JSON-equivalent model allows working with application as document

80. What is a “component”? A “unit of work” An actual “widget on the screen” The result of a decision about an implementation strategy A context for further decisions ALL OF THE ABOVE

81. Structural Scoping

82. A “demands block” fluid.demands("fluid.uploader.totalProgressBar", fluid.uploader.multiFileUploader", { funcName: "fluid.progress", container: "{multiFileUploader}.container" });

83. A “demands block” “demanded function name” “context name to match” fluid.demands("fluid.uploader.totalProgressBar", fluid.uploader.multiFileUploader", { funcName: "fluid.progress", container: "{multiFileUploader}.container" }); “contextualised path reference” “pseudoargument name” “disposed function name”

84. Designing for Context

85. Kettle: Server-side JS Built on the powerful new Node.js platform Liberating the power of asynchronous I/O Infusion as application framework Choose where markup gets rendered The stupendous power of fine-grained IoC on the server Natural, familiar environment for Web developers and designers

86. Node.js performance (1 year ago) http://zgadzaj.com/benchmarking-node-js-testing-performance-against-apache-php/ Concurrency Level: 1000 Time taken for tests: 21.162 seconds Complete requests: 100000 Failed requests: 147 (Connect: 0, Receive: 49, Length: 49, Exceptions: 49) Write errors: 0 Total transferred: 8096031 bytes HTML transferred: 1799118 bytes Requests per second: 4725.43 [#/sec] (mean) Time per request: 211.621 [ms] (mean) Time per request: 0.212 [ms] (mean, across all concurrent requests) Transfer rate: 373.61 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 135 821.9 0 9003 Processing: 1 40 468.5 25 21003 Waiting: 1 30 64.1 25 12505 Total: 2 175 949.1 26 21003 Percentage of the requests served within a certain time (ms) 50% 26 66% 33 75% 36 80% 39 90% 55 95% 94 98% 3030 99% 3090 100% 21003 (longest request) Concurrency Level: 1000 Time taken for tests: 121.451 seconds Complete requests: 100000 Failed requests: 879 (Connect: 0, Receive: 156, Length: 567, Exceptions: 156) Write errors: 0 Total transferred: 29338635 bytes HTML transferred: 1889607 bytes Requests per second: 823.38 [#/sec] (mean) Time per request: 1214.510 [ms] (mean) Time per request: 1.215 [ms] (mean, across all concurrent requests) Transfer rate: 235.91 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 38 321.8 20 9032 Processing: 0 565 5631.0 51 121380 Waiting: 0 262 2324.1 41 52056 Total: 29 603 5641.7 73 121431 Percentage of the requests served within a certain time (ms) 50% 73 66% 78 75% 82 80% 83 90% 89 95% 105 98% 4251 99% 13205 100% 121431 (longest request) Node 0.1.103 Apache 2.2.14

87. Wrapping Up Tools for everyone: – ARIA – jQuery – Infusion Give Infusion a try and let us know We’re a friendly community!

88. Wrapping Up Please fill out an evaluation.

89. Questions? http://fluidproject.org