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.
08448380779 Call Girls In Greater Kailash - I Women Seeking Men
Architectures for Inclusive Design
1. Architectures for Inclusive Design
Colin Clark, Fluid Project Technical Lead
Adaptive Technology Resource Centre
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
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. 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
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. 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. 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
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. Architecture is hard
• Code is hard to understand and maintain
• Goals of a good architecture:
• Enable growth
• Allow for outside extension
• Manage dependencies
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. Three Pillars of OO
1. Inheritance
2. Encapsulation
3. Polymorphism
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. 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. Encapsulation
• Hide away the internals of an object
• Define a contract through methods
• Traditionally, data is considered opaque
21. Polymorphism
• The ability for different objects to
respond to the same method in different
ways
• Interface vs. implementation
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
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. Traditional MVC
Model
n
atio
oti c
State Query State Change
ge N
n
Cha
View Selection
View Controller
User Gestures
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. 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. Model View (controller)
Model
Change Noti cation
State Query State Change
View
Framework
32. Declarative Programming
Declarative programming is a programming
paradigm that expresses the logic of a
computation without describing its control
flow
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. Interoperable
• Web formats are:
• Plain text
• Declarative
• Openly published and standardized
• This means they are adaptable and extensible
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. 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. 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
52. ARIA
• Accessible Rich Internet Applications
• W3C specification in the works
• Fills the semantic gaps in HTML
• Roles, states, and properties
• Live regions
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. 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. 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. The Problem with Roles
Roles are driven by 1980’s era desktop widgets
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. 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. 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. Accessible Architectures
• Interoperable apps are accessible apps
• Your application state is content, too
• Extensible: allow for alternatives
• Personalisable
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
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. 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