Category Archives: Uncategorized

2015 Kurogo Conference Mega Post

This post is the culmination of all the live blog posts I made at the 2015 Kurogo Higher Education Conference…a practice I have that I like to call a “MEGA POST.”  Like any other conference I attend, I make it a point to document the sessions I attend.  This keeps me engaged at all times (often difficult in post-lunch sessions), gives me notes I can refer to later on, and provides a source of information for others who could not attend.

If there’s anything I took away from this conference, it’s that higher education institutions have EXACTLY the same kinds of needs.  The differences between solutions are simply variations on a theme.  Whether it’s transactions like course selection and tuition payments, MarCom needs like campus tours and micro sites for alums, or student life needs like safety escorts, the needs are the same.  Only the implementations differ.  What differentiates the Kurogo platform is that it’s open source, and campuses are actively contributing to it.  A great example of this is was Matt Willmore’s announcement of Notre Dame’s contribution of several open-source modules to the Kurogo community (see my post on Student/Citizen Development with the Kurogo Platform below).  This is a welcome gift to the community, and should be encouraged.  By the way, Notre Dame was a wonderful host…thanks Matt!

With that, here’s my list of posts.  I hope you find them useful.

Monday, April 27

Tuesday, April 28


Why email is the devil

Email is the devil, I’m sure of it.  Unfortunately, it’s the official form of communication for many institutions, including my own.  I’m inextricably tied to it, and somewhere over the last few years, it turned me into something I never thought I’d be:  a hoarder!  Well, the devil doesn’t work alone, you have to give him the power.  Let me explain the whole sordid tale, and what I did after I saw the light…


  • Gmail is awesome
  • Saving every email you get is a terrible idea
  • There are better tools than email for most work-related communication tasks
  • My email “rules of engagement”

I like to keep my communication organized; always have.  Over the years, I’ve used a range of email programs including Outlook, Mac Mail and Thunderbird.  Of course, I’ve used web clients for almost as long, but I always found it comforting to store everything locally.  No matter which program I used, I carefully created folders to neatly store everything for future reference.  And I do mean EVERYTHING.  I had literally hundreds of folders that broke things down by project, organizational affiliation, function, you name it.  It got to the point that my folders were so granular, it became a more-than-once daily conundrum about which folder to store my email in…not to mention the mileage I was putting on my trackpad!

Several months ago, one of my staff members introduced me to a better way of managing Gmail that literally changed my life.   Yes, literally.  The article that describes “the way” is here:  In simple terms, it takes advantage of the multiple inbox extension, activation and actual use of keyboard shortcuts, filters and labels.  While I got used to doing things this way, I kept my Mac Mail client running for a couple weeks.  After only three days, I knew there was no turning back.  I was able to fly through my email in minutes per day, not hours.  This was the nice “clean break” I needed.  However, I still had about seven years of email I felt obligated to do something about.

While I used Mac Mail for my work email account and Thunderbird for my personal email account, thankfully I did not have to worry about manually exporting and importing .mbox files.  Way back in 2007, I created a Gmail account that I used exclusively as a repository for both my personal and work accounts.  After seven years of forwarding from two accounts, I had over 75,000 emails stuffed in that account.  I had to figure out the best way to move it all into the Gmail account I use now.  I found a great article that explained how to do exactly that here:  Once set up, the transfer process happens automatically (that took about four days, in case you’re wondering).  Of course, none of THAT email was organized, so I had a ton of email sitting inside an “archive” label to sort through.  This was a challenge, even with my newfound Gmail-fu.  A number of custom filters – some of them used only once and then deleted – eliminated about half of the mail I knew I didn’t need, leaving me with about 40,000 emails.  I’m committed to going through these, 1,000 per day until they’re all gone.

Digressing briefly, I have to mention some of the other work-related communication tools I’ve been using a lot recently.  What these tools have in common is fitness of purpose:

  • Basecamp:  an extremely popular online project management and communication tool.
  • Pivotal Tracker:  an agile project management tool used by software development teams.
  • Slack:  this is the tool that really helped me see the light and redeemed me.  Slack aggregates all communication associated with a project.  It combines the best parts of instant messaging with twitter, and – most importantly – has integration hooks into literally thousands of tools that developers use, like github, basecamp, errbit, pretty much every bug/feature tracker, and more.  There’s no better tool out there that lets teams clearly see who’s doing what and when.  It’s amazing and I can’t imagine working without it.

Anyway, as I was going through those 40,000 emails last weekend, I had an epiphany:  the vast majority of this email just doesn’t matter anymore.  Many were critically important at the time they were written, but they’re basically worthless now.  This fact doesn’t change the reality that I still have to go through all that mail, but it made deleting things so much easier.

It’s now painfully obvious to me why storing every email is a bad idea:

  1. Not every email is equally useful (duh)
  2. Finding important stuff gets harder over time
  3. “Inbox zero” becomes more elusive
  4. It’s a liability (maybe even legally)
  5. It’s a heavy psychic weight to carry

Here are my new not-quite-perfected email “rules of engagement:”

  1. Use email only for official communications that have a shelf life greater than one month.  This includes:
    • Budgeting
    • Contracts
    • Staffing, i.e. hiring, firing, merit increases
    • Strategic things that directly affect the bottom line
    • CYA (we all have our unique reasons)
  2. Delete everything more than one year old, unless it fits into rule #1 (even then, it’s probably less important than you think).  I’m shocked at how few of my precious old emails contained any information worth keeping.
  3. Inbox zero, ALL THE TIME.  There’s no good reason to keep anything in your inbox.  Waiting on an answer from someone? Tag it and archive it.  Need to schedule a bill payment on the 24th?  Tag it and archive it.  Delegated a task to your staff?  Tag it and archive it.
  4. Use the right tool for the job.
    • Got a sensitive topic?  Pick up the phone!  Or better yet, pay that person a visit.
    • Collaboratively riffing on an idea in real-time?  Use Google Hangouts, Skype, Face Time, or GoTo Meeting.
    • Need to communicate with a project team?  Use Basecamp, Pivotal Tracker, Slack, etc.
    • Got to write something short for the world to see?  Use Twitter, Facebook, Tumblr, RSS, etc.
    • Got to write something long-form for the world to see?  Use a blog or an old-fashioned web site.
    • Editing a document with colleagues?  Use Google Drive (docs, spreadsheets, presentations) or Box.  There are lots of options in this space.

Email is still a great tool when you want to send someone the equivalent of a memo, but for most of the work I do today, email is the wrong tool for the job.  Don’t let email steal your life!


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”