Architectures for Inclusive Design




Colin Clark, Fluid Project Technical Lead
Adaptive Technology Resource Centre
Things we’ll talk about
•   Priorities for software

•   What is software architecture?

•   Object oriented programming

...
Who am I?

Who are you?
Fluid...
            http://fluidproject.org

• Is an open source community of
  - Designers
  - Developers
  - Accessibili...
What We Do
• Offer design advice and resources
• Contribute to other communities:
  - jQuery UI
  - Dojo
  - W3C Accessibi...
Software priorities
Some questions...

1. What’s the most important thing on your
   computer?
2. What’s your favourite piece of software?
3. ...
Content is king
• Your stuff.
• The things you do with your stuff.

  Software architectures need to be focussed
  on enab...
Software shouldn’t suck
• Good software...
  • Doesn’t crash
  • Doesn’t eat your data
  • Helps you accomplish your goals...
Architecture
What is architecture?

•   Concerned with the shape of software
•   Defines the structure and APIs of a system
•   Highly a...
Architecture is hard

• Code is hard to understand and maintain
• Goals of a good architecture:
  • Enable growth
  • Allo...
Architectural tendencies

 •   Loose coupling
 •   Shallow dependency hierarchies
 •   Interoperability & semantics
 •   L...
Object Orientation
Goals of OO

•   Define a system in real-world terms
•   Hide away the guts of an implementation
•   Create small, useful m...
Three Pillars of OO

1. Inheritance
2. Encapsulation
3. Polymorphism
Inheritance
• A way of structuring dependencies and
    reusing code
•   Defines the identity of an object (is a)
•   Mamma...
Inheritance
                              AbstractMap
                                       Method




                  ...
Encapsulation

• Hide away the internals of an object
• Define a contract through methods
• Traditionally, data is consider...
Encapsulated Object

              Method
     Method




                       Method
              Data

              ...
Polymorphism
• The ability for different objects to
  respond to the same method in different
  ways
• Interface vs. imple...
Crumbling Pillars
• Inheritance is brittle and ineffective
• Composition (has a) works better
• Encapsulation can lead to ...
Model View Controller
Model View Controller

•   Model is the application data and associated
    behaviour

•   View presents the model and dri...
Traditional MVC

                 Model


                          n
                      atio
                 oti c
St...
The Problem with Controllers


•   Controllers are the least defined part of the
    equation

•   What’s “glue?”

•   Alwa...
Controllers and Frameworks

•   Orginally, in Smalltalk, the Controller managed the
    low-level event loop for an applic...
Model View                      (controller)



            Model
          Change Noti cation




   State Query         ...
The Web
Architecture of the Web

• Separation of structure from presentation
• Declarative
• Stateless
• Interoperable
Structure vs. Presentation


<ul class="fl-list-menu">
                               .fl-list-menu li {
  <li>
            ...
Declarative Programming

 Declarative programming is a programming
 paradigm that expresses the logic of a
 computation wi...
Declarative Programming

         what
         not



         how
Compare & Contrast
Compare & Contrast


Scroller
Imperative
if (!highlighted) {
    ctx.globalAlpha = 0.3;
} else {
    // Draw the scroll track rectangle.
    var clientL...
Declarative

                                      .fl-thumbnailContainer {
                                      
   posit...
Statelessness


“The Web is broken. It can’t remember me
between requests”
Statelessness

• The Web is stateless for a reason: it scales
• State is visible, not encapsulated

        http://build.fl...
Interoperable
• Web formats are:
 • Plain text
 • Declarative
 • Openly published and standardized

• This means they are ...
How assistive
technologies work
Assistive Technologies
• Present and control the user interface in
  different ways
• Not just screen readers!
• Use built...
OS AT APIs
•   A channel for UI introspection
•   What’s on screen?
•   How are things labelled, organized, etc.?
•   What...
The Role-Based Model

•   Just about every API works the same way
•   Give each UI widget a name
•   e.g. slider, tabs, di...
View Hierarchies
Accessibility Inspector
Like getting a flood of data through a
                 straw...
Hearing it in action
Web Accessibility
Opaque Markup
// These are tabs. How would you know?
<ol>
 <li><a href=”#cats”>Cats</a></li>
 <li><a href=”#dogs”>Dogs</a>...
Opaque Markup: Tabs
ARIA

• Accessible Rich Internet Applications
• W3C specification in the works
• Fills the semantic gaps in HTML
• Roles, s...
Roles, States, Properties
• Roles describe widgets not present in HTML 4
  • slider, menubar, tab, dialog
• Properties des...
Using ARIA
// Now *these* are Tabs!
<ol id=”animalTabs” role=”tablist” tabindex=”0”>
 <!-- Individual Tabs shouldn’t be fo...
Adding ARIA in Code
// Identify the container as a list of tabs.
tabContainer.attr("role", "tablist");

// Give each tab t...
The Problem with Roles




Roles are driven by 1980’s era desktop widgets
The Problem with Roles




   The Web is driving hybrid UIs
The Problem with Roles




     ... even on the desktop
Analyzing User Interfaces
Inline Edit Roles


Button?
Inline Edit Roles


            Text Field?
Inline Edit Roles


Button?
               Text Field?
Inline Edit Behaviours
   Read-only




  Activatable
                  Editable




       Undoable
Open Architecture
Open applications

• Transparent models
• Event-driven
• Loosely-coupled and separable

• Case study: Fluid Infusion
Transparent Models

• Break open data encapsulation
• Publicly share models in standard formats
• Allows others to see int...
Events

• Interesting moments in the life of your app
• e.g. onSave, onSelect, onOpen, etc.
• Use events to wire up app, a...
Data Change Events
                        Change Request




          Guard                            Observer



     ...
Accessible Architectures

• Interoperable apps are accessible apps
• Your application state is content, too
• Extensible: ...
Slate     FSS Themes


Mist



High Contrast
UI Options & FSS
UI Options: High Contrast Theme
Subcomponents

•   Provides loose coupling between parts (IoC)

•   Look up dependencies by name, and the
    framework wi...
Subcomponents Illustrated
Uploader


 Dialog Box
Uploader


 File Queue
Uploader

  File Row
Uploader




 Progress Bar
Where does this lead us?

• Today, ATs just describe what’s visible
• Imagine alternative representations
• Knowledge of s...
Accessible architectures are...
•   Introspective

    •   Declarative programming

    •   Transparent models

    •   De...
Questions?
Upcoming SlideShare
Loading in...5
×

Architectures for Inclusive Design

955
-1

Published on

An overview of creating accessible user interface architectures. Covers the role of architecture in development, the limitations of traditional Object Oriented and MVC paradigms, and an overview of how assistive technologies work. Presented as a guest lecture in University of Toronto Faculty of Information's INF 2187H: Introduction to Inclusive Design course.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
955
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
19
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Architectures for Inclusive Design

  1. 1. Architectures for Inclusive Design Colin Clark, Fluid Project Technical Lead Adaptive Technology Resource Centre
  2. 2. Things we’ll talk about • Priorities for software • What is software architecture? • Object oriented programming • Model View Controller • Case study: the Web • How do assistive technologies work? • Rethinking the role-based paradigm • Techniques for open architecture
  3. 3. Who am I? Who are you?
  4. 4. Fluid... http://fluidproject.org • Is an open source community of - Designers - Developers - Accessibility experts • Helps other open communities • Consists of universities, museums and individuals
  5. 5. What We Do • Offer design advice and resources • Contribute to other communities: - jQuery UI - Dojo - W3C Accessibility • Build Infusion, our JavaScript application framework • Build Kettle, our JavaScript server-side infrastructure
  6. 6. Software priorities
  7. 7. Some questions... 1. What’s the most important thing on your computer? 2. What’s your favourite piece of software? 3. Why do you use software?
  8. 8. Content is king • Your stuff. • The things you do with your stuff. Software architectures need to be focussed on enabling creativity and contribution, for everyone.
  9. 9. Software shouldn’t suck • Good software... • Doesn’t crash • Doesn’t eat your data • Helps you accomplish your goals • Is fast enough to keep up with you • Can grow over time with your needs
  10. 10. Architecture
  11. 11. What is architecture? • Concerned with the shape of software • Defines the structure and APIs of a system • Highly abstract: recognition of patterns • Best done iteratively, not all up front
  12. 12. Architecture is hard • Code is hard to understand and maintain • Goals of a good architecture: • Enable growth • Allow for outside extension • Manage dependencies
  13. 13. Architectural tendencies • Loose coupling • Shallow dependency hierarchies • Interoperability & semantics • Less code
  14. 14. Object Orientation
  15. 15. Goals of OO • Define a system in real-world terms • Hide away the guts of an implementation • Create small, useful modules • Enable reusability
  16. 16. Three Pillars of OO 1. Inheritance 2. Encapsulation 3. Polymorphism
  17. 17. Inheritance • A way of structuring dependencies and reusing code • Defines the identity of an object (is a) • Mammals, Felines, Cats and Lions • Vehicles, Cars, and Trucks • Fruit, Apples, Oranges • Lost of other contrived examples...
  18. 18. Inheritance AbstractMap Method Method Method Data Method IdentityHashMap HashMap Method Method Method Method Method Method Data Data Method Method PrinterStateReasons LinkedHashMap Method Method Method Method Method Method Data Data Method Method
  19. 19. Encapsulation • Hide away the internals of an object • Define a contract through methods • Traditionally, data is considered opaque
  20. 20. Encapsulated Object Method Method Method Data Method
  21. 21. Polymorphism • The ability for different objects to respond to the same method in different ways • Interface vs. implementation
  22. 22. Crumbling Pillars • Inheritance is brittle and ineffective • Composition (has a) works better • Encapsulation can lead to overzealousness: • Cuts off access to useful information • Assumes custom structures are better than plain old, interoperable standards
  23. 23. Model View Controller
  24. 24. Model View Controller • Model is the application data and associated behaviour • View presents the model and drives the interaction logic • Controller is glue, mediating access between model and view
  25. 25. Traditional MVC Model n atio oti c State Query State Change ge N n Cha View Selection View Controller User Gestures
  26. 26. The Problem with Controllers • Controllers are the least defined part of the equation • What’s “glue?” • Always referred to as the non-reusable part • MVC has been warped over the decades
  27. 27. Controllers and Frameworks • Orginally, in Smalltalk, the Controller managed the low-level event loop for an application • In Web apps, they’re usually responsible for parsing requests and dispatching • These are both things that high-level frameworks do for us now • E.g. The event loop in a Web browser
  28. 28. Model View (controller) Model Change Noti cation State Query State Change View Framework
  29. 29. The Web
  30. 30. Architecture of the Web • Separation of structure from presentation • Declarative • Stateless • Interoperable
  31. 31. Structure vs. Presentation <ul class="fl-list-menu"> .fl-list-menu li { <li> padding:0; <a href="#">Link Text</a> } </li> .fl-list-menu li a {   <li> display:block; <a href="#">Link Text</a> padding: 12px 0px 12px 12px; </li> text-decoration: none;   <li> font-weight: bold; <a href="#">Link Text</a> outline: none; </li> } </ul>
  32. 32. Declarative Programming Declarative programming is a programming paradigm that expresses the logic of a computation without describing its control flow
  33. 33. Declarative Programming what not how
  34. 34. Compare & Contrast
  35. 35. Compare & Contrast Scroller
  36. 36. Imperative if (!highlighted) { ctx.globalAlpha = 0.3; } else { // Draw the scroll track rectangle. var clientLength = this._getClientLength(); ctx.fillStyle = theme.scrollTrackFillStyle; ctx.fillRect(NIB_PADDING + 0.5, 0.5, clientLength - 2*NIB_PADDING, thickness - 1); ctx.strokeStyle = theme.scrollTrackStrokeStyle; ctx.strokeRect(NIB_PADDING + 0.5, 0.5, clientLength - 2*NIB_PADDING, thickness - 1); } var buildHandlePath = function() { ctx.beginPath(); ctx.arc(handleDistance + halfThickness + 0.5, // x halfThickness, // y halfThickness - 0.5, Math.PI / 2, 3 * Math.PI / 2, false); ctx.arc(handleDistance + handleLength - halfThickness - 0.5, // x halfThickness, // y halfThickness - 0.5, 3 * Math.PI / 2, Math.PI / 2, false); ctx.lineTo(handleDistance + halfThickness + 0.5, thickness - 0.5); ctx.closePath(); }; buildHandlePath(); // Paint the interior of the handle path. var gradient = ctx.createLinearGradient(handleDistance, 0, handleDistance, thickness); gradient.addColorStop(0, theme.scrollBarFillGradientTopStart.replace(/%a/, alpha)); gradient.addColorStop(0.4, theme.scrollBarFillGradientTopStop.replace(/%a/, alpha)); gradient.addColorStop(0.41, theme.scrollBarFillStyle.replace(/%a/, alpha)); gradient.addColorStop(0.8, theme.scrollBarFillGradientBottomStart.replace(/%a/, alpha)); gradient.addColorStop(1, theme.scrollBarFillGradientBottomStop.replace(/%a/, alpha)); ctx.fillStyle = gradient; ctx.fill();
  37. 37. Declarative .fl-thumbnailContainer { position: absolute; top: 0pt; <form class="fl-thumbnailContainer"> left: 0pt; ... bottom: 0pt; </form> overflow: auto; width: 185px; z-index: 100; }
  38. 38. Statelessness “The Web is broken. It can’t remember me between requests”
  39. 39. Statelessness • The Web is stateless for a reason: it scales • State is visible, not encapsulated http://build.fluidproject.org:8095/engage/artifacts/view.html? accessNumber=M2000.38.97&db=mccord&lang=en
  40. 40. Interoperable • Web formats are: • Plain text • Declarative • Openly published and standardized • This means they are adaptable and extensible
  41. 41. How assistive technologies work
  42. 42. 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
  43. 43. OS AT APIs • A channel for UI introspection • What’s on screen? • How are things labelled, organized, etc.? • What states are things in? • UI Roles, states, properties
  44. 44. The Role-Based Model • Just about every API works the same way • Give each UI widget a name • e.g. slider, tabs, dialog, button, text field • Names imply behaviour • For AT users, names define interactions
  45. 45. View Hierarchies
  46. 46. Accessibility Inspector
  47. 47. Like getting a flood of data through a straw...
  48. 48. Hearing it in action
  49. 49. Web Accessibility
  50. 50. Opaque Markup // These are tabs. How would you know? <ol> <li><a href=”#cats”>Cats</a></li> <li><a href=”#dogs”>Dogs</a></li> <li><a href=”#gators”>Gators</a></li> </ol> <div> <div id=”cats”>Cats meow.</div> <div id=”dogs”>Dogs bark.</div> <div id=”gators”>Gators bite.</div> </div>
  51. 51. Opaque Markup: Tabs
  52. 52. ARIA • Accessible Rich Internet Applications • W3C specification in the works • Fills the semantic gaps in HTML • Roles, states, and properties • Live regions
  53. 53. 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
  54. 54. Using ARIA // Now *these* are Tabs! <ol id=”animalTabs” role=”tablist” tabindex=”0”> <!-- Individual Tabs shouldn’t be focusable --> <!-- We’ll focus them with JavaScript instead --> <li role=”tab”><a href=”#” tabindex=”-1”>Cats</a></li> <li role=”tab”><a href=”#” tabindex=”-1”>Dogs</a></li> <li role=”tab”><a href=”#” tabindex=”-1”>Gators</a></li> </ol> <div id=”panels”> <div role=”tabpanel” aria-labelledby=”cats”>Cats meow.</div> <div role=”tabpanel” aria-labelledby=”dogs”>Dogs bark.</div> <div role=”tabpanel” aria-labelledby=”gators”>Gators bite.</div> </div>
  55. 55. 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); });
  56. 56. The Problem with Roles Roles are driven by 1980’s era desktop widgets
  57. 57. The Problem with Roles The Web is driving hybrid UIs
  58. 58. The Problem with Roles ... even on the desktop
  59. 59. Analyzing User Interfaces
  60. 60. Inline Edit Roles Button?
  61. 61. Inline Edit Roles Text Field?
  62. 62. Inline Edit Roles Button? Text Field?
  63. 63. Inline Edit Behaviours Read-only Activatable Editable Undoable
  64. 64. Open Architecture
  65. 65. Open applications • Transparent models • Event-driven • Loosely-coupled and separable • Case study: Fluid Infusion
  66. 66. Transparent Models • Break open data encapsulation • Publicly share models in standard formats • Allows others to see into your application’s data and state
  67. 67. Events • Interesting moments in the life of your app • e.g. onSave, onSelect, onOpen, etc. • Use events to wire up app, and talk to the world • Key feature: notifying people about changes in your model
  68. 68. Data Change Events Change Request Guard Observer Guard Observer Guard Observer Apply Change Method Method Data Method Method Method Data Method Method Method Data Method
  69. 69. Accessible Architectures • Interoperable apps are accessible apps • Your application state is content, too • Extensible: allow for alternatives • Personalisable
  70. 70. Slate FSS Themes Mist High Contrast
  71. 71. UI Options & FSS
  72. 72. UI Options: High Contrast Theme
  73. 73. Subcomponents • Provides loose coupling between parts (IoC) • Look up dependencies by name, and the framework will instantiate them for you • Users can implement their own version or configure alternatives
  74. 74. Subcomponents Illustrated
  75. 75. Uploader Dialog Box
  76. 76. Uploader File Queue
  77. 77. Uploader File Row
  78. 78. Uploader Progress Bar
  79. 79. Where does this lead us? • Today, ATs just describe what’s visible • Imagine alternative representations • Knowledge of structure, data, actions • Completely different UI optimized for the user?
  80. 80. Accessible architectures are... • Introspective • Declarative programming • Transparent models • Describe behaviour, roles, and state • Adaptable • Declarative programming • Loose coupling & inversion of control • Separation of structure and presentation
  81. 81. Questions?
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×