Categories
Accessibility Technology

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.

Enjoy!

 

Friday, March 21

 

Thursday, March 20

 

Wednesday, March 19

 

Tuesday, March 18

 

Monday, March 17

Categories
Accessibility Technology

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!

 

Presenter:

 

RESOURCES

 

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

 

Agenda

  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.
Categories
Accessibility Technology

AccessU at CSUN 2014

Presenters:

INTRODUCTION

Sharron Rush kicked off the event:  This is the second time we’ve brought AccessU to CSUN, we want to bring the excitement and education of our normal three-day event to you here.  We want to bring very specific and useful tools you can use.  We’ve broken this event into three tracks:   advocacy and usability (Sharron), responsive design (Derek), IT/program & project management (Elle).  Attendees are welcome to move between the three tracks as they like.

Elle:  We want to encourage collaboration and sharing of your experiences.  This is a participation sport!  There will be team exercises and things to work on together.  If there are topics you REALLY want to talk about, feel free to contribute to the conversation.

Derek:  as Elle said, we really do encourage collaboration.  Derek then reviewed housekeeping tasks and the day’s schedule; the schedule is at a web site the presenters set up here:  http://csun.simplyaccessible.com/  Copies and transcriptions of the question boards posted at the back of the room will be posted to the web site later on.

Just so you understand the rest of this post, you should know that I opted to follow the track Elle ran because a) her past presentations have been extremely coherent, useful, and focused on product management – which is something I care about – and b) I’m a bit of a fanboy.  Onward!

 

FIRST DEEP DIVE:  9:30 – 10:30 AM

SLIDE:  Key Points

  • Accessibility should pay for itself
  • Building the business case for accessibility is about relationships and trust
  • Building the business case for accessibility is also about being a change agent

Innovation and accessibility are closely related

 

SLIDE:  Discussion:  Biggest Challenges

  • What are the primary road blocks that you’ve experienced in your organization when trying to build the business case for accessibility?
  • Which departments or roles pose the greatest challenge to your success?
  • What one action could you take next to move this forward?

Comment:  executive buy-in is often a problem.  Lack of prioritization often means that accessibility gets lost in translation.

 

SLIDE:  How does Accessibility…

  1. Align with your company’s vision?
  2. Align with your company’s business goals?
  3. Position itself as a solution for other teams’ challenges?
  4. Align with your company’s methodologies?
  5. Support your company’s specific user groups?

Answering these five questions will help you orient yourself when discussing accessibility with everyone in your organization.  In many ways, you should be the expert in your organization about organizational objectives and processes.  This will buy you the credibility you need when having those key conversations.

 

SLIDE:  Team exercise:  company profile

At this point, Elle and Sharron’s groups were together.  We broke up into our constituent groups after going through the bullets below.  After that, “Elle’s group” worked on building a company profile.

  1. Organization type and size (government agency, non-profit, publicly traded corporation)
  2. Who are you?  What do you do?  What’s your company’s passion?
  3. Over-arching business philosophies (eg, Kaizen, Mobile First, Six Sigma, UCD-User Centered Design, ISO9000)
  4. Is there a single project that your whole company is focused on right now or in the near future?

It’s important for you to have as much information as possible about your company’s goals and the people you’re going to be talking to about accessibility.  Here are some key questions you should ask before getting started:

  • Do you have existing development standards at your company?  Can you point your web developers to a document that explains how to build – for example – a form?
  • Do you have a design pattern library?
  • Do you have an accessibility statement?  This is really helpful from a policy perspective.
  • How “established” is your organization’s digital governance?  Is it well-organized?
  • Describe your SDLC.  Does what you say you do bear any resemblance with what you actually do (the quote “we’re a fragile shop” drew a lot of laughs).
  • Get to know your users!  Do it with personas, channels, target markets, etc.  Does your company have regular contact with it’s customers?  What is the typical workflow for people to get their voice heard.
  • What is your organization’s background with accessibility?
  • Has your organization faced any legal action with accessibility?  Sometimes these conversations start based on legal action.

One of the attendees talked about the H&R Block lawsuit that was recently settled.  It entailed relatively minor punitive damages ($133K), but resulted in the institution of major changes in the company’s internal processes.  This included creation of a Chief Accessibility Officer, regular audits, and more.  It’s much better to be pro-active than be forced to do something as the result of legal action.  This has other negative results too, i.e. a tarnished brand image.

Another attendee wanted to talk more about building accessibility into project budgeting.  We did later on when talking about procurement…

What do you do to prevent legal Action?  Having a documented organizational intent with a policy, milestones, and a feedback mechanism often helps to prevent lawsuits.  Lainey Feingold has a great session on this topic later this week, which everyone should attend.

Especially important after talking about legal action:  don’t forget that this effort is about the users!

The Prioritization Matrix (the break out activity)

  • Y-Axis:  Level of Visibility (who could see this web site)
  • X-Axis Regulatory / Legal oversight
  • These axes results in four quadrants, which help you as an accessibility professional target the items that need the most attention in your organization.

As mentioned above, when building the prioritization matrix, you really do have to be more well-versed in organizational priorities than just about everyone else.  When you meet with the people you need to evangelize to, you should probably focus on those items that fit into the top right quadrant (high priority, high regulatory / legal oversight).

I built a matrix with a group of four higher education folks.  Here were the groups:

Government team:  everything is driven by some form of a regulatory requirement.  Some of the regulatory requirements are competing.  Agency home pages are highest priority.

For-profits:  we’re in all four quadrants.  For highly visible public sites where there’s no login or transactions, inaccessible sites will be passed over by our customers.  Internal customer sites are low visibility, but high oversight (i.e. – job postings).  Internal tools used by specific users are generally low visibility/low regulatory and legal oversight.

Higher Ed:  we’re closer to the government model, with a lot of items in the top-right quadrant.  Systems that are required include student information and HR systems, course management tools, and so on.  Items that fit into static web sites often include marketing content that may have high visibility but not a lot of regulatory oversight, i.e. campus tours, about us pages, etc.

Laying your company’s profile over this matrix will help you build your strategy and communicate your message to all stakeholders.

Build your “campaign speech” and include it in every meeting about accessibility you put on, i.e. roadshows, brown bag lunches.  Senior executives should NOT hear this evangelist language from you first, they should hear it from their close colleagues.  Share your wins and share the credit…this will help keep the momentum going.

Question to Elle from the group:  How to you make the roadshow sexy?  While this gets people’s attention, it may not be the very best thing to say…but historically, there are three things that drive online innovation:  gaming, pornography, and accessibility 🙂  It also helps to be a high energy person.  Hackathons help a lot by driving developer excitement.

The Five Ps:

  1. Planning
  2. Policy
  3. Procurement
  4. Process
  5. Professional Development

 

SLIDE:  Procurement & Compliance

“Cabbages and Oak Trees:”  what are we going to be when we grow up?  You need quick wins with fast turnaround times…but you also need to build something that’s lasting.  You need governance and metrics to be a part of the scaffolding, and you also need to consider whether your organization will fall under ADA Section 3, CVAA, and Section 508.

Process and integration of accessibility is cyclical.  That said, you need to be at the source, at the very beginning…BEFORE the project gets into the kickoff phase.  In other words, be a part of the procurement process!  “Procurement is the ingredients, and implementation is the cake you bake.”  Customers measure the cake, not the quality of the eggs.

Procurement toolkit:

  • Define standards – what are you obligated to meet?  Be comprehensive but not redundant.  Incorporate explicit advice for how you deal with specific things like UX and code standards.
  • Develop a public policy –  key features:  statement should be aligned with your brand promise.  Show the steps you’ve taken and the progress you’ve made.  Show an example of the accessibility features on your web site.  Be sure you have a feedback mechanism with someone minding the store…there’s no point in have a contact e-mail if nobody ever reads or responds to it.
  • Map out your objectives!  Align your initiatives with specific dates.
  • Take an inventory of your vendors.  The main difference between platforms and services is that a platform can snake it’s way into every crevice of your organization, so it’s important to get it right!

Pre-lunch questions:  how many services does your organization use?  For most large organizations, it’s probably in the hundreds.

 

AFTERNOON:  The Gist of What You Missed, 1:30 – 2:30 PM

Each group leader reviewed what their group talked about during their respective morning sessions.

Sharron:  We are all about the people that we serve,  and that includes both the people with and without disabilities in our organizations.  We define accessibility with respect to people, not standards.  In that vein, we use these concepts:  Perceivable, Operable, Understandable, Robust.  Our group had representatives from government, corporations, and higher education.  We start our process by enlisting executive sponsors, internal and external stakeholders, launch a usability test.  When then talked about the process parts and implementation of a “game plan” over a “roadmap.”  Why do we call it a game plan and not a roadmap?  Because a game plan is more fluid/cyclical and a roadmap is linear.  We then thought through the players we need to involve in our game plan, and how to coach them to work to the best of their ability.  How do we cross-train them if necessary?   We did a quick look at EasyChecks as well.  W3C’s Education and Outreach Working Group is also working on a series of tutorials which will be rolled out over the next six months or so.

 

Elle:  We talked about building the business case, and then we split out into our “building the business case” groups.  Bold statement:  accessibility should pay for itself, because it builds so many benefits for your company.  It’s also about building relationships of trust.  It’s about being a change agent within your organization.  We talked about developing a company profile risk matrix so that you can map your organization’s risk profile to it.  You then have to be strategic and target those tasks that will have the biggest impact.  Once you have these elements, you take your show on the road and take every opportunity you have to communicate your message.  We also talked about the pillars of accessibility, the 5 Ps:  Planning, Policy, Procurement, Process, Professional Development.  We talked about developing a policy page that articulates your organization’s plan, your roadmap, and a place to highlight your “wins” so visitors can see what you’ve done.  Also be sure to have a mechanism in place that allows visitors to provide feedback, and then actively monitor it!  We finally talked about procurement as a key part of the process that you should bake your accessibility concerns into.

 

Derek:   two philosophies of responsive design.  One is the “old method” of fixed width, the other “new method” is building for resolution ranges.   Responsive design allows you to provide your customer with more than one way to accomplish a task.  Mobile devices use gestures that may have different meanings depending on the operational mode, i.e. a swipe down means something different when accessibility features are turned on.  Historically, designers have looked at design problems in a very constrained way.  We spent some time looking at mobile devices and how they work with accessible technology turned on.  We showed how the rotor control works on iOS.  We also reviewed a few key concepts, most notably how a change in layout / display may require a change in interaction, role (markup), source order, alt text, state or other property.  A good practical example of this would be a mega-menu.

 

AFTERNOON DEEP DIVE, 2:30 – 3:15 PM

Back with Elle again…

Procurement as a priority – how do you make it successful?

You can’t sit in on every single conversation where accessibility might be mentioned.  You’re best off getting your language into the boilerplate documentation used by your organization in their day-to-day business.  An example of this would be RFP & RFQ documents.  BUT…how do you make sure that the vendors you’re talking to fully understand what you need from their products with respect to accessibility?

  1. Boilerplate language needs to be in your documents
  2. Vendors need to demonstrate tool accessibility via testing, or a VPAT
  3. Have live discussions with your vendors; use open-ended questions i.e. “please describe your understanding of and commitment to open web standards and progressive enhancement” or “describe what POUR means to you” or “please describe your testing process with individuals, machines, etc.” “who will pay for accessibility deficiency fixes after purchase?”

Question to Elle from an attendee:  is there a list of vendors who are invested in making their products accessible?  Not exactly, but there are a number of vendors that do have excellent reputations.  Loop 11 is a good vendor for doing remote user testing.

 

Design Pattern Library

Standardization of designs wherever possible is extremely important for providing contextual meaning.  Yelp is one company that has published their design patterns and is worth looking at.  LinkedIn has an interesting way of dealing with developing design pattern standards:  they have a sort of “lab space” where things are being tested but vetted by their accessibility team.  Having a versioning system (SVN, github, mercurial) is important as well.

 

Role-Based Responsibility Requirements

Take all the roles in your organization that have contact with digital content and make a matrix of what their responsibilities are, and how their roles influence the organization’s response to accessibility.  Accessibility teams that operate as a stand-alone entity generally aren’t as effective.

 

Distributed Responsibility:  Long-Term Growth

(this description is a transcription of a graphical slide, so the translation may not make sense…my apologies)  Project Management Links directly to Accessibility, while accessibility itself is split between the following tasks:

  • Analysis
  • Architecture
  • Interaction design
  • Content Strategy
  • Graphic Design
  • Prototyping
  • Development
  • Quality Control

We broke up into five groups, each taking on a particular HTML control type.  My group took on the slider control.  We spent our time talking about the specific requirements that would be required to ensure the control is accessible, and who would be responsible for handling each slice of the responsibility pie.  We ended up having ten different roles (i.e. business analyst, marketing, content people, developers, designers, interaction designers, testers, UX researchers, and product managers) to handle each item.

Resources including slide decks, photos, resource links, transcriptions of items written on the easels, etc. will be available at sateach.ex/csun

I hope you find this – the first of many posts – helpful.

Categories
Accessibility Technology

The CSUN 2013 Web Track Mega Post

Greetings, fellow web accessibilistas!  (not to be confused with accessiballistas, the little-known and even less-documented accessible siege engine of yore).

As you may have gathered if you followed my live blog posts a couple weeks ago, my interest in attending the CSUN 2013 conference was almost exclusively web-related.  Now that it’s been a couple weeks and I’ve had some time to reflect, I figured it would be a good idea if I consolidated everything into one mega-list.  This year, there were several times when I wish I could have been in two places at once.  Hopefully this gives you a pretty representative sampling of what was on offer web-wise this year.  Follow me @paulschantz for more web-related topics, including accessibility, project management, web development and design philosophy, thoughts on working in higher education, bad clients, off-color humor, and other ephemera.  Enough self-promotion…on with the list!

Pre-Conference Seminar:  Google Accessibility

Day One:  February 27, 2013

Day Two:  February 28, 2013

Day Three:  March 1, 2013

Categories
Accessibility Technology

IBM’s WCAG 2.0 Compliance Web-Costing Model

  • Phill Jenkins IBM Research, Human Ability and Accessibility Center
  • Dan Shire IBM Ineractive, IBM Canada

Why this presentation?  Our experience with Government of Ontario is relevant to organizations and web sites trying to estimate the costs of accessibility.

Questions that need answers:

  • What does it take to make a website accessible (from scratch)?
  • What does it take to keep it that way?
  • What are the opportunities and challenges?

Project Steps

  • Identify candidate sites and sample pages
  • Assess sample pages for accessibilty
  • Estimate cost to test, repair and maintain
  • How to apply project experiences to sites and policy

7 week timeline

Slide showing an IT project life cycle showing user-centered design.  UX, including accessibility and support for inclusive design, should be at the heart of your project – this can be integrated into every phase of the project.

QUOTABLE QUOTES:

  • “Most organizations take several runs at procurement before they get it right”  This is a true statement and I agree with it.
  • “How many of you work in corporate IT departments?” (several hands raise)  “Many of your colleagues in government and higher education wonder why it costs so much to make things accessible.  In those environments, you take care of the HTML and CSS and you’re done.. it costs so much more in corporate environments because those environments are very risk-averse.”  I find this characterization suspect.

TWO FACTORS TO CONSIDER

  1. Look and feel:  expensive to update – design and significant coding changes.  If you get accessibility wrong, it can be broken everywhere.
  2. Content can be relatively dynamic and change frequently.  Compliance can be a problem.

How often do organizations refresh their sites?  Varies, but roughly every 3 years (evidence is highly anecdotal)

99% of businesses are small and medium sized business (less than 200 employees)

Provided a very detailed description of IBM’s analytical approach to their testing methodology, with breakdowns of costs of web accessibility remediation, with hours of effort by role…

…and it was at this point that I couldn’t take any more and walked out.  Everything they’re saying is true, but my god, I think IBM can make anything mind-numbingly boring.

%d bloggers like this: