Category Archives: Uncategorized

The (not so) Surprising Parallels Between Responsive Design and Accessibility

This is my third session from the first day at the CSUN conference.  This session is hosted by my friend George Zamfir, who I met at this conference last year.  The session guide describes George’s session like so:  “Responsive design has borrowed principles & best practices from accessible design.  Learn about both and how to apply them to your projects.”

Presenter:  George Zamfir (@good_wally)




In this post, I’m going to dispense with my normal slide-by-slide narrative structure.  George’s presentation moved way too fast and had lots of builds. 😉


George discovered that responsive design was a great way to build accessibility into his projects.  He showed us some of his previous work on the Scotiabank web site.  This ended up being TWO projects:  first for the desktop version of the site, then the mobile responsive version of the site.  He also worked on the mobile version of the bank’s credit card application.


What do all assistive technologies have in common?

  • They don’t care much about design, and they care to change it for the user (a lot like RSS readers)
  • Content trumps design, regardless of screen size
  • RWD is not about the design, it’s about updating the design to bring out the content



Visual, Auditory, Mobility, Cognitive & Speech.  Don’t measure people through the disability lens – which automatically focuses on what people are NOT able to do.  We now measure disability by what people CAN do.


Accessibility is contextual, so we should cater to users’ context.  You’re not necessarily engaging with someone working on a desktop computer with a large monitor, keyboard and mouse anymore.  He referred to a study of how people hold their phones and also the W3C’s BAD (Before After Demo) page.

  • One simple tip:  adding padding around text links increases the “hit size”
  • Keyboard accessibility translates well into touch-friendly interfaces.
  • Use native controls wherever possible.  On the bank side, they used <div> instead of <select> control, which was a problem when they went mobile.


Design for the edge cases (mobile first design)

If you start with a small screen, prioritization really matters. A variation of this model is designing for edge cases.  If you design for the harshest conditions first, the in-between cases are much easier to work out.  Consider accessibility as one of your edge cases!


RWD is a champion for A11Y, we have common goals for our users.


Question:  how do you handle navigation in RWD?  I target the simplest possible device and design progressively.

Question:  Do you do anything special about device orientation changes?  Answer:  why would you change the content?  Perhaps you change the layout, but you should not change the content.

Question:  What is your process when you have the luxury of a “clean sheet” design…how do you handle the lowest common denominator?  I like to start with everything besides the content.  We built the framework, and the content just fits into that framework.

Question:  what about hiding content based on context?  How do you handle that? Well, that’s probably not the best way to go…you’re probably doing it wrong if you’re doing it that way.



Foundations of RWD:  fluid foundation, media queries, responsive images.  In short:  Make your layout flexible!

  • Use ratios (ems) and percentages instead of absolute values (px).
  • Adapt to the size of the viewport:  width = device-width, initial-scale=1
  • What apple does is assume that the normal viewport size is 960 pixels, so if you don’t add the viewport declaration, you can get pages with text that’s very small-looking on a small screen.
  • Media Queries in CSS:  start with smallest screen first, and then the larger screens are additive over that definition.
  • Responsive Images:  for simplicity’s sake, start with this: use max-width:100%, height: auto;

Quirks in Web Standards, Browsers, and Screen Readers

This is my second session of the first day at the CSUN conference, and “takes a look at quirks and bugs in browsers and screen readers, what they mean for users, and how to avoid, fix, or work around them.”  (description is from the conference session guide).  As someone who is actively involved in building consistent web experiences (i.e. browser compatibility), I’m interested in how Ian does this when you add accessible technology into the mix.  Any misinterpretations of Ian’s presentation are entirely my own.  Any errata, please let me know!

Presenter:  Ian Pouncey, Accessibility Specialist, BBC (@IanPouncey)





Ian took some time to establish his credibility…

Used to work on the Yahoo! home page, and more recently has been a web developer at the BBC.  Been doing this for about 14 years.  Written a book about CSS from Wrox publishing.

Room was made up of developers, technical folks, screen reader users, and those obliged to come (a little humor).

Ian shared a few slides that were pretty humorous related to “skip to content” links, wherein the humor was related to where you placed the accent on the word content (hopefully he’ll post those slides).



Shared a couple pages about skip links from Gez Lemon and Terrilll Thompson, and then demonstrated dynamic skip link code with window.location.hash.



Ian showed form error listings and focusing on fields with errors.  Unfortunately, window.location.hash only works reliably in IE!

Ian did a demo of a skip link bug when using off-page content on iOS7.  He prefers using content off-top rather than off-left.  This technique however can result in some interesting behavior, notably showing the skip link after an up-swipe gesture to turn on VoiceOver, and then navigation after that makes the screen go completely blank.

Another option is to use off-screen CSS clipping, which unfortunately results in a lot more code.  This clipping technique is used on about 98% of the BBC web site, so if you want to see it at work, head over there 🙂



Next, Ian shared an ARIA landmark bug in iOS6.  This bug basically announces ALL landmarks in VoiceOver as simply “landmarks,” which is not very helpful.  This bug is resolved by adding a heading to every landmark.



Finally, Ian shared a bug with Live Regions.  You can’t always rely on live regions to provide information to the AT at the appropriate time.

Solution:  JavaScript-added content can be read once it’s been written to the screen.  So, you can build an empty div that quietly waits for content to be written into it.  Be sure to use role status with the assertive attribute.

Implementing ARIA and HTML5 into Modern Web Applications (Part Two)

This is part two of a two-part presentation.  Catch up on part one here:  Introduction to ARIA and HTML5, Part 1

I’m typing this introduction before the presentation begins, and as I understand it, this session will be more technical than the morning session.  I’m not sure how many in-depth code samples will be included (the resources link below hints at what we’ll be talking about), so I’m making an educated guess that I may not be able to capture every nuance.  My apologies in advance if this is the case.





EVENT PLUG – TPGBB (The Paciello Group Bug Bash)

  • Wherein you and TPG can ID and squash AT bugs
  • Thursday, March 20, 5:30 – 6:30 PM
  • Suite 3233, Harbor tower, Manchester Grand Hyatt





Diving into some HTML5  – an overview of the session

Steve Faulkner talked briefly into his involvement with his having a role in the creation of the HTML specification.  His specific interest is in how APIs speak to AT.



Getting Simple

Getting to use native HTML controls makes things simpler for the developers and the AT.



HTML5 Demo – details/summary

Here’s an example of the “HTML code triangle” we’re all used to:


<summary> label </summary>

Some content


When fully supported, you’ll be able to use native HTML controls without having to use any complicated JavaScript.  In the example above, clicking details would expand and show the contained elements.

Steve then demonstrated in CodePen an example of the code above, and how vastly simplified it is to render these UI elements.  This will make UI/UX designer’s lives much easier.



Chrome, Opera, and Safari have implemented this

Keyboard = 1/2 implemented



Steve then gave a description of how the code above is exposed to the AT APIs (i.e. MSAA).   Put simply, it’s exposed as a <div>, however, it’s not an accurate description of how it’s represented within the DOM.  He then proceeded to show how this looks when viewed through the “Accessibility Viewer” tool.  The aviewer tool is an object inspection tool available from the Paciello Group’s web site at

Not all information is necessarily passed through the API and readable by aviewer.  The hope is that every browser will expose the same API Names, Roles, and States.



What We Want

  • We want to be able to see what’s actually there.
  • We also want to fill the gaps in general support in FF, IE, and webkit browsers



Steve showed and described the example above, only this time embellished with ARIA code inserted.



Showed the details summary here as a working example:

The properties of the code on this page are properly exposed by the API, and thus readable as you would expect by aviewer.




Creating a modal dialog that works with keyboard and prevents users from accessing ‘disable’ content is the holy grail…

Being able to do this within native HTML is something that sure would be awesome.  See next slide…



What we get for free:

  • Focus moves to modal dialog when displayed
  • Focus stays until it is dismissed
  • Content not in the modal dialog is really disabled
  • ESC key dismisses it
  • <dialog> = role=dialog



What we need to add (this only works in Chrome with Canary plug-in at the moment)

  • Accessible name to dialog:  <dialog aria-label=”text”>
  • Currently when the dialog is dismissed, focus moves to <body> when it needs to move to control that triggered dialog display:  can be polyfilled using scripting.

Steve demonstrated accessible modal dialog, once again with CodePen; he was unable to tab “out” of the modal dialog.  It works like a JavaScript alert()



The “good oil” on implementing custom dialogs (I didn’t capture these links, but they’re available in the TPG source slides from the “Resources” link above).

  • Juicy Studio – Custom Built Modal Dialogs
  • The Incredible Accessible Modal Dialog
  • WAI-ARIA design pattern – modal dialog



Input type=number

What we get:

  • Correct role and value information
  • Keyboard operable

Exposed as spin buttons



Input type=range control

Implemented in all browsers.  However, default styling in IE is pretty funky, and they all look different from each other.  Bottom line:  you get everything for free.



There are conformance rules for HTML5, but they can be difficult to decipher.  Steve has a “Using ARIA in HTML” document available for download which can help.



A large part of what’s been consuming Steve’s life in his role on the HTML5 specification group is figuring out which ARIA Roles, States, and Properties can be used on any HTML element.



ARIA Validation

  • Use of ARIA in HTML5 is non-conforming and probably always will be.  It doesn’t make any difference, it still works.
  • Easiest method is to use the HTML5 DOCTYPE with ARIA markup and then validate it using the W3C NU markup checker:

<!DOCTYPE html>




Live Regions

  • Allows user to be notified of content changes
  • Typically for content that changes automatically
  • Content change may exist separate to what has focus
  • Live Regions facilitate these notifications

ARIA overcomes gaps between what JavaScript has “traditionally” done in web browsers to emulate desktop applications.



Karl’s favorite thing to say:  “What is this thing & what does it do?”

  • Chat, error logs, etc. (role=’log’)
  • Status messages (role=’status’)
  • Urgent message requiring immediate notice (role=’alert’)
  • Stock ticker (role=’marquee’)
  • Timer/Clock (role=’timer’)
  • Progress indicator (role=’progressbar’)
  • None of the above (role=’region’)



How important is the content?

  • aria-live=’polite’ (waits patiently, default for most roles)
  • aria-live=’assertive’ (interrupts output, default for alert role)



What’s being changed?

  • I’m adding stuff (aria-relevant=’additions’)
  • I’m removing stuff (aria-relevant=’removals’)
  • I’m changing text (aria-relevant=’text’)
  • I’m replacing stuff (aria-relevant=’all’)

Makes relevant changes to the DOM within that live region.  You can change these properties together as needed.



What matters?

  • aria-atomic=’false’ (default behavior, only announces changed node)
  • aria-atomic=’true’ (presents entire contents)



What’s my name

A redux of aria labels that was covered in Part One



<div role=’alert’ aria-label=”Errors’>

Please correct the following errors:


Significance of the code above is that it will announce all the mistakes made in a form all at once, which is pretty handy.



Karl then demonstrated some of the challenges when using live regions with a chat he had set up at:

He also showed a web-based slideshow called “shower”

Download and play with Karl’s JQuery plug-in at

Short break here…

Karl went about soapboxing:

“ARIA is a LIE and your HTML doesn’t do anything.  They are instead a polite request to the browser about what to do with our code, which is then transformed into a DOM.”

Principle of Least Astonishment:  things should behave consistently




  • Keyboard and Focus management
  • Form validation
  • Mode conflicts
  • Solutions, workarounds, and considerations



Problem with Custom Controls (not native UI)

Usually created with generic elements like <divs> and <spans>

  • Not keyboard focusable
  • Have a default tab order
  • Behavior unknown

Best solution is to use native controls, or manually define keyboard focus and behavior needs.



Keyboard Issues in a Nutshell

  • Reachability:  via tab order, globally defined shortcut, activating another widget
  • Operability:  all functionality should be doable via keyboard and mouse input.



To be accessible, ARIA input widgets need focus.

  • Tabindex=”0″ element becomes a part of the tab order
  • Tabindex=”-1″ element is not in tab order, but focusable

Each widget should have only one stop in the tab order.  All of your widgets should be reachable via keyboard.  Hans then gave a demonstration of a tree widget, tabbing both into and out of it using JAWS.  This demonstration also pointed out the danger of wrapping a page with a role of application.

An alternative for a roving tabindex is the aria-activedescendant=”<idref>”



Every widget needs to be operable by keyboard.  Common keystrokes are:

  • Arrow keys, home, end, page up, page down, enter, space, esc
  • Mimic navigation in the desktop environment when possible:
  • Always manage and keep track of your focus.  Never let it get lost.

To demonstrate focus, Hans showed a table that allowed deletion of columns of data.  After deleting a column, the previous column received focus.



Skipping Mechanisms

  • Ability to skip content is crucial for screen reader and keyboard users
  • Skip links may be out of fashion and often misused, but users still need to be able to skip.
  • Alternatives:  collapsible sections, consistent shortcuts, custom focus manager



Form validation

  • ARIA makes form validation easier to manage:  aria-required & aria-invalid states, role=”alert” flags validation errors immediately.  Inline and error summary used together are most effective.
  • Validation summaries make invalid entries easier to find

Create a programmatic connection between validation messages and their associated fields.  Maybe there needs to be a W3C specification about how AT is supposed to behave (there’s one for UA).  Hans provided a demonstration of a sample form with required fields.  Tabbing away from a required field activated the “required” error when tabbing into the following field.  He attempted to mark up the fields as live regions, but it didn’t work very well.



Fallback solutions for link buttons

There’s no real consensus on links versus buttons.  Set role=”button” to make links look like buttons for screen readers



Mode conflicts, i.e. Role=Application

  • Screen readers normally browse in ‘virtual mode.’  This means it navigates a virtual copy of the web page.  It intercepts all keystrokes for its own navigation (i.e. “H” for heading navigation.
  • For dynamic web apps, virtual mode may need to be turned off.  Interactive widgets need to define the keystrokes themselves; content needs to be live, not a virtual copy; automatically switches between virtual and non-virtual mode.
  • role=”application”:  screen reader switches to non-virtual for these elements; must provide all keyboard navigation when in role=”application” mode; screen readers don’t intercept keystrokes then, so typical functions will not work.




  • For apps with reading or editing sections (e-mail client)
  • When applied to a container inside an application role, the screen reader switches to virtual mode.

Only use application role when your application actually IS a web application.



Explain to users how Rich Internet Applications work

Put some hidden text at the beginning of the page to explain.



The perfect dialog, in theory

  • Use role=”dialog” combined with aria-labelledby (for dialog title), aria-describedby (for dialog message text)
  • Focus management
  • For modal dialogs:  prevent virtual navigation to background using aria-hidden=”true”


Campus Readiness: Communicating IT Changes to the Campus Community

Title:  Campus Readiness:  Communicating IT Changes to the Campus Community


  • Jo-Ann Cuevas, Campus Readiness Specialist, Stanford University
  • Ammy Woodbury,  Campus Readiness Specialist, Stanford University
  • Christine Jacinto, Assistant Director of IT, Humanities & Sciences, Stanford University


SLIDE:  Campus Readiness at Stanford University

  • 28K constituents
  • About 20 client-facing projects released every year
  • 2 people responsible for getting the word out to the campus


SLIDE:  When an IT Need is ID’ed…

  1. A document management solution to facilitate collaboration and manage data security
  2. PM receives approval to start the project
  3. PM creates charter
  4. PM assembles team, including campus readiness
  5. Campus readiness reviews the charter
  6. Have a meeting to review the charter (impact, audience, training, marketing, documentation, communication).  Campus readiness forecasts hours based on the discussion.


SLIDE:  Communication Plan

A living document that’s updated frequently.  Focuses on communication across phases, IDs key stakeholders and end users.  This functions as a to-do list and a kind of “shadow project plan.”  Includes a running narrative and summary.

Four main sections to the rest of the communication plan:

  1. Awareness and engagement:  who do we need who will be informed about the project?  Might include help desk, key decision-makers, governance groups, administrative assistants, power users, and so on.
  2. Training and documentation:  all the elements we need to create for ongoing needs, current employees, new employee on-boarding.  Instructional designers decide on the best approach for training, because it will vary.
  3. Reinforcement and post-implementation feedback:  what does help desk need to promote for struggling users.  We use qualtrix for survey-taking.
  4. Ok, I missed one step here – my bad.  Can’t type fast enough…


Plan Execution

Includes a ton of work:  E-mail communication, hands-on training, surveys, change training, UX testing, documentation, service promotion, e-learning dev, campus communication, instructional design, user advocacy, presentations.

We function as the user advocate and engage in a lot of geek-to-English translation.


SLIDE:  Case Studies

Case 1:  Mobile Device Management

  • Early intervention led to iteration in the development
  • UX testing led to significant improvements in usability.
  • Adoption was strong
  • When adoption plateaued, Campus Readiness held user interviews determining that further improvements were largely out of Stanford’s control.  Promotion methods were altered to address those issues and use different approaches.

The dev team embraced Campus Readiness input as they saw the impact on adoption.  Team talked a bit about some bumps in the room with AirWatch and how they mitigated some of those issues.  UX issues are considered so important now that the team can delay roll-outs to accommodate needed changes.


Case 2:  Converged Communications VoIP Rollout

Change that affects administrators; on-site training that was all-inclusive accommodated client’s busy schedules.  We started with Humanities and Math & Science departments, then went campus-wide.  Phones would be on the desk after staff went through training, ready-to-roll.

It’s definitely a good idea to reach out to your connectors, ’cause someone is always the “go-to” tech helper in a department.


Case 3:  International Travel Data Security

It’s no longer just about visas and vaccines, it’s also about data security!  You have to be conscious of where your data is going.  We have three preferences of how we want people to work (in order of preference)

  1. What would we most like you to do?
  2. What’s a good approach?
  3. What’s the minimum required?

Their shop has loaner iPads for overseas trips.  If the user MUST take their own computer, it is imaged prior to departure and is restored upon their return (and PRIOR to the computer going back on the network).


Case 4:  e-mail and calendar upgrade

At launch, the campus readiness team provides:

  • Video tutorials (what’s new and different)
  • Daily tips by e-mail
  • Front-line support
  • Demos
  • Hands-on training
  • Campus partners

Each session had a roomful of people, since implementation of such a product affects pretty much everyone.  We would also engage with key stakeholders and representatives from each area to hear what their pain points were.  We would then help these “decentralized” folks formulate their own plans for communicating changes to their teams.  This helps build community.


A “Campus Readiness Specialist” has experience with:

  • Communications/business writing
  • ID and training
  • Presentations to large and small groups
  • Help desk support
  • e-learning development
  • UX testing

Key Qualities

  • Warm, friendly and outgoing style
  • Ability to rapidly learn new systems
  • be a geek-to-English translator



Are you a part of the PMO?  No, we’re matrixed but mostly report to documentation team.

What communication mechanisms do you use…Social Media?  We do use Facebook and Twitter, we also use an IT access page as well as a space for messaging on our ticketing page.  We also use the “Stanford Report,” a daily e-mail communication managed by university communications.

Do you participate in requirements gathering phase?  Yes!  But not always…

How many people normally attend your weekly monthly meetings?  Depends, from 40 or less on weekly meetings to 81 for monthly meetings.





Big Data Enables Student Retention: Student Success & SAP HANA

Title:  Big Data Enables Student Retention:  Student Success & SAP HANA


  • James David Hardison, DMD, MBA, Industry Principal, Higher Education
  • Vince Kellen, Ph.D., Senior Vice Provost Academic Plan Analytics and Technologies


SLIDE:  Screen shots of the “Powers of Ten” film

What if you could…(I smell a sales pitch coming)

  • Manage data, have the current data, have the right answers


SLIDE:  30 year old data modeling is slow and inefficient, in-memory is the new hotness!  (My words, not theirs)

HANA:  High Performance ANalytic Appliance


SLIDE:  HANA for Higher Education through University Alliances

  • SAP donates licenses to 1,300+ univesities
  • 1.2 million students educated on HANA
  • Certifications, etc.


SLIDE:  Newton’s Second Law of Motion

Students at risk are not likely to change their behavior without intervention.  Used snowball rolling downhill as an example…easy to stop at the top of the hill, but irresistible at the bottom.


SLIDE:  Using Fast Analytics to Help Improve Student Retention

High response rates to mobile micro surveys, about 40,000 responses in 4 weeks.  Questions include things like “how much are you working this term, how stressed are you (1-5 Likert scale), do you think you’ll be successful this term, etc.

In-memory analytics requires different architecting of the data modeling; We don’t do traditional ETL (Extract Transform Load techniques).

Took an approach of making data available, rather than keeping it “close to the vest.”

We can answer the question:  do we know how many left-handed Hungarian ping-pong players we retained?  How do we break our analysis into little pieces to answer practical problems and questions.

Also collecting “technographic” information on student device types and OS, frequency of use, number of devices, etc.

Been prototyping this with lecture capture and full-text search (what he referred to as “wayfinding”), i.e. ability to find specific terms, apply metadata, ability to link out to other materials, and so on.

Graph databases are generally not used by university degree audit reports, which precludes the use of “what if” scenarios.  This is useful for day-to-day business needs.  Incidentally, graph database technology is widely used in the Social Media space, but for some reason it seems to be all new and exciting to many of the wide-eyed higher ed attendees.  Hmm…

They’re using HANA data with Tableau to make pretty graphs.  Also, showed an Enrollment Plot of Chemistry 105


SLIDE:  Academic Health Notifications: View in Student Mobile App


SLIDE:  Using this data in a personalized student profile



SLIDE:  Taxonomy?  Automatic metadata?  Automatic atomic metadata?

  • Let learners navigate an a/v stream
  • Let the system learn what the top terms are.  Let the system map terms to concepts.  Let instructional designers lightly bump the taxonomy.

Thinking of Google AdWords-style presentation of information that’s relevant to the student’s click-stream and status.


SLIDE:  Organizational Considerations

  • Hired Ph.D. level data scientists (there was some turnover)
  • Translated old architectures to HANA and retired old IR data warehouse
  • Opened data, many have access, personal data is protected
  • Raised skill sets in colleges and units and provide support.


SLIDE:  Some best practices

  • Be safe and secure
  • Be collegial
  • Help improve data quality
  • Be open-minded and inquisitive
  • Share (don’t be a taker)



Do you plan to include co-curricular data into your system?  Obvious items are participation in clubs and organizations, and surfacing internships and job opportunities.  Yes, it’s on the roadmap.

Are you collecting data on effectiveness of tutoring?  Yes.