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:  http://klinger.io/post/71640845938/dont-drown-in-email-how-to-use-gmail-more  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:  http://email.about.com/od/gmailtips/qt/How-To-Move-Mail-From-One-Gmail-Account-To-Another-Using-Only-Gmail.htm  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!


CSUN 2014 Web Track Mega Post

As usual, I like to make a post that sums up my entire conference experience…I call this the “Mega Post.”  As you may have guessed from the titles of the sessions I attended, I’m interested in the web track.  If the web is your bag, you just might find all this helpful.



Friday, March 21


Thursday, March 20


Wednesday, March 19


Tuesday, March 18


Monday, March 17

How to Win the Accessibility 3-Legged Race

This is my second session from the third day at the CSUN conference.  This description of this session from the event guide says that “We need accessible web products from our design agencies.  How do we make sure they deliver on that?  We provide practical advice drawn from experience.”  These guys definitely have the best session titles, and all their sessions I’ve attended were entertaining and had great usable content.  The very first slide has My Little Pony, so we’re definitely off to a strong start.  This might be my last post of the conference, since I have a train to catch.  Onward!






George and Billy talked a bit about themselves and what they do.  They then said they’d help us with the often awkward “agency-client handshake.”  #awkwardhug



  1. Set yourself up for success
  2. Create strategy and stick to it
  3. Be realistic about your team’s a11y knowledge
  4. Use testing tools AND test with users
  5. ABC always be closing

Round-the-room discussion


If you ask a simple question as a client like “is the product keyboard accessible” and they come back with Ctrl-Shift-Alt-F2-w-t-f”  That will tell you a lot about the company.  Common excuses and comments:

  • An excuse is “on our web site we sell ___ so blind people will not visit our web site.
  • Accessible web sites are ugly


Set yourself up for success

  • Ask lots of questions.  Early on.
  • If you see a lot of checklists early on, that is often something to be concerned about.
  • If you’re in an AGENCY:  “we need an accessible web site” is not a good requirement.  Read between the lines…is it a legal requirement, or do they have corporate buy-in?  What if you’re the only agency who is successful in delivering accessible web products?  Make it something that you can sell, list it on your web site!
  • If you’re a CLIENT, talk to your peers.


Create a Strategy and Stick to It

  • AGENCY:  work the client to develop milestones and figure out how to get there.  Make it an integral part of your workflow, it’s becoming a competitive advantage.  Bake it in at every stage.  Your account/project manager needs to clearly articulate how accessibility is done.
  • CLIENT:  ask one question:  what’s your accessibility strategy?  Pro tip:  if you have style guides / development guidelines that include accessibility, share those with the agency.  Compromise is OK as long as it’s realistic.


Be realistic about your team’s accessibility knowledge

  • AGENCY:  use your strongest web guy for the job; your SharePoint guy ain’t gonna cut it!
  • You need your whole team to know accessibility.  Teamwork, not “the one guy who knows VoiceOver”
  • Start small, ask your team to take the short online AODA / Customer Service course (a google search will turn this up).  Pro tip:  put a requirement in your RFP that the agency must take  this course.  It won’t make them experts, but it will give them a baseline knowledge.
  • CLIENT:  testing only with screen readers is not going to cut it.
  • Make sure you’re comfortable with the agency’s accessibility knowledge.  Don’t get into meetings / calls with the sales team, ask for the PM, BAs, designers, etc.  Ask for examples of their work with other accessible projects.  If the agency has no proven knowledge of accessibility, hire a third party.


Use testing tools AND test with users

  • Find the testing tools that work for you and use them.  It needs to be a part of your workflow.
  • AGENCY:  Test with users with disabilities.  You don’t need to invest in expensive testing tools. Just turn on VoiceOver on your Mac or High Contrast Mode in Windows.  Other tools we recommend are WebAIM WAVE toolbar, aViewer, Web Accessibility Toolbar, Color Contrast Analyzer, etc.
  • CLIENT:  Test with users with disabilities or at least simulate with assistive technologies.  Use automated testing tools, especially for regularly-posted content.  Be smart about prioritizing:  1 big issue on 1 page versus 1 small issue on 80 pages.


Always be Closing

  • “We’ll just do it in phase 2″ never happens
  • Use MVP (minimum viable product) for accessibility
  • Write a report that clearly depicts the accessibility results.
  • Do good work and don’t be afraid to show the client you can do it again, this is your chance to articulate that in the report.
  • CLIENT:  spot-check, then sign-off on it.  It’s better to launch with some accessibility issues than not launch at all. Planning for some remediation is OK.  Ask the agency to report on the results of their accessibility strategy/work completed.  HINT:  you don’t actually care how they report.  Major benefit?  You flip the accessibility process upside down!  You’re basically asking for two things:  do the accessibility work and tell me about what you did.

Making Accessibility Compliance Claims – VPATs and GPATs

This is my first session from the third day at the CSUN conference.  This description of this session from the event guide says that “methods and techniques for developer valid, defensible claims of accessibility compliance in public sector procurements including VPATs and GPATs.”  In my experience working with vendors of IT products and services, one thing I’ve learned is that while they may say they have a VPAT,  we often provide the vendor with tips and guidance that they then sell right back to us!  This is the first time I’ve been in a session put on SSB BART Group, I’m curious to see what they’re all about.  The Arizona Wildcats pep team was outside making some noise, which was kinda fun.


  • Tim Springer, SSB BART Group
  • Matt Arana, SSB BART Group




SSB has been around for about 20 years, we’re a completely accessibility-focused group.  They cover pretty much the gamut of technology platforms and have done a huge number of audits and reviews.


A compliance claim is “An official statement of compliance of [something] with a [standard/guideline]”

  • Section 508 does not currently define a conformance claim process
  • WCAG has a conformance claim process

Compliance claims are often used in procurement, regulatory, and litigation situations.  Some causes for concern include claims without substance, claims against nebulous requirements and claims that are false.


Laws, Standards and Guidelines

  • WCAG is published by W3C; there are two versions, 1.0 and 2.0.
  • From the basis of most web accessibility standards, including 508

WCAG is strongly aligned with EU and 508 laws.  508 is purely a federal law.

CVAA (US) requires communication and video that go over the Internet to be accessible.  Primarily targeted at communications software and equipment manufacturers, video service providers and producers of video content.

ADA is a US civil rights law, and application to IT is tricky.  There are no technical standards for compliance.


Scope of Coverage:  If it has to do with 1s and 0s, it may be impacted

  • 508:  all EIT
  • ADA: public and employee facing EIT
  • CVAA:  Communications and video EIT
  • May also see information and communication technology (ICT) used

Where are you selling, who’s buying, and what are the risks?  These should be considered as part of your “go to market strategy.”



  • VPAT is a registered trademark of the ITIC:  Information Technology Industry Counsel
  • Current version 1.3, ITIC accessibility policy page has this
  • VPATs have been largely superseded by WCAG compliance claims, especially in the private sector.
  • WCAG is likely to be globally harmonized on



  • A GPAT is Government Product (or Service) Accessibility Template
  • Takes general procurement language and puts it into a document that can be used.  GSA quick links provides GPAT formats for procurement types; BuyAccessible Wizard can generate them de novo.
  • Government may accept a VPAT in lieu of a GPAT
  • While formatted differently, they contain materially the same information.

GPAT and VPATs look essentially the same, but GPAT includes more formalized details about total supported provisions (full, partial, not).  This allows for easier scoring of products.  However, the GPAT may not supersede the VPAT due to lack of awareness, and is more likely to be superseded globally by WCAG compliance claims.  A healthy discussion followed about the trickier aspects of VPAT/GPAT statements of full | partial | not supported.


Statement Creation

What are actually trying to do?  Make it accurate, and it should be done by someone who understands both the system and accessibility.  Have some documentation behind the process…claims should be well justified based on the demonstrable accessibility of your system.  This is good from both a regulatory and sales perspective.  So…you really should do some internal testing for audit purposes.


Auditing Requirements and Constraints

Technical Reqs (1194.21-1194.26), Functional Reqs (1194.31), and Support Reqs (1194.41).  Automatic testing makes up about 25% of the actual testing you need to do on a product to ensure it’s accessible.  Manual testing makes up close to 50% of that effort.  Global testing makes up about 25% of total testing and represents systemic testing, i.e. error messaging, color palettes, etc.  Technical testing is not easy, you need a lot of domain expertise to do it properly.


Audit Approach

Technical testing is broken down each section into best practices.  508 testing is broken down into about 130 separate tests to make sure a tool’s sample pages are web-accessible.  Functional testing involves real-world use cases tested by people with disabilities; can they accomplish the task in the use case?

Lessons Learned: Accessibility Theory vs. Implementation Reality

This is my fifth session from the second day at the CSUN conference.  This description of this session from the event guide says that “standards-compliant accessibility does not always work as expected in real-life implementations…TPG/CGI will share techniques for dealing with inconsistent support by browser and AT products.”  If it’s anything like the other TPG presentations, there will be lots of content and resources…I will do my best to keep up :-)


  • Hans Hillen, The Paciello Group (@hanshillen)
  • Jennifer Gauvreau, CGI
  • Stephen Cutchins, CGI




It SHOULD work versus it DOES work

CGI and TPG have been working together for about two years and made a choice very early on that they would adopt WAI-ARIA and HTML5.  They’ll cover 3 use cases:  theory, use cases demonstrations and workarounds


Browsers and Screen Readers

  • Time + Budget = Targeted Testing Profiles.
  • Profile 1:  Win7, IE8 and IE9, JAWS (v12, v13, v14)
  • Profile 2:  Win7, FF, NVDA (latest stable build)


ARIA Landmarks

  • We weren’t using landmarks and wanted to use them.
  • Theory:  We had heard that it was easy to implement on existing and new pages, supported regardless of (X)HTML version, a real win-win
  • Reality:  initially worked as expected; as real content was added, strange things started happening.
  • Hans then showed what code looks like both with and without landmarks, and followed up by demonstrating with JAWS 12.  When a field is focused and does not have an aria-label on the region, JAWS (v12) reads the entire content of the main landmark.  IE used all the content of the region as fallback content.  Solution:  add an empty title=” ” tag in the body.


JAWS 13+ announces region before each form field

Solution:  wrap the fields in a <div> or <form> and define role=”form” on the form container.  JAWS stops announcing “region” before announcing the form element, but new issues sometimes appear.

Pair new HTML5 <main> element with ARIA role=”main”

  • Adding landmarks wasn’t necessarily guaranteeing a great and consistent user experience.


ARIA Landmarks: Lessons Learned

  • Need to test at a unit (landmark) and integration (page) level
  • Do no harm
  • You may not run into these issues if you have simple static content.  Most of this stuff crops up with forms and CMS-generated content


ARIA Dialogs: a common design pattern

  • Theory:  WAI-ARIA dialog requirements describe this in detail; it worked as expected with test content.
  • Reality:  when adding large sections of complex content to a dialog, things didn’t work as expected.  What would happen is that the dialog would display the contained content halfway down and focus would be on an element far down the page.

Question:  as a fix, could you make the close button the first focusable element?  Answer:  Yes, but there was a reason why we didn’t go that route (although I can’t remember what that reason was).  Instead, we made the heading of the dialog the first focusable element (tabindex=”-1″).  You can also force the dialog role so that it is read in “document mode.”

ARIA Dialogs: Lesson learned – adapt to design challenges

  • Create POC early on using “real world” content, not short strings of boilerplate text
  • Expand design patterns and authoring best practices to meet new design realities
  • Support the use of reusable frameworks like JQuery UI to design/build once and then reuse from a centralized solution for ease of maintenance


Use case 3:  Icons

Define alt text to make HTML images accessible is perhaps the first accessibility concept every developer learns.  However, as web designers and developers have embraced new methods for displaying icons, we were faced with a new set of accessibility challenges to consider

Requirements:  equivalent text content for  icons used to convey content, status or meaning; allow for user personalization; clients and developers need cost-effective scalable solutions.

Reviewed high contrast mode and user-defined style sheets

  •  HTML images should be used for icons conveying information.
  • CSS background images should not be used to convey content and only used for decorative images or as a redundant visual cue for adjacent text.

Designers prefer CSS image solutions (sprites) because they load faster.  Unfortunately, HTML images don’t inherit high contrast theme.  No fallback text for CSS background images.

Solution: build a High Contrast Mode detection script and use font-based icons.

Test your icon approach

Takeaways:always test your solution in high contrast mode, user defined stylesheet, images disable, css disabled


Key Themes

  • Do no harm
  • Adapt to design challenges
  • Be maintainable
  • Be vocal:  id bugs and tell vendors

Continuing Adventures in Higher Ed & Technology