Tag: project management

Categories
Accessibility Technology

The 2015 CSUN Mega Post

Hey there!

When I come to the CSUN conference, I write about every session I attend.  When I’m all done with the conference, I make sure I gather up all my posts into one <echo>MEGA POST</echo>.  In the past, I felt strongly pulled toward the more technical web track sessions, because I run a web development shop.  This year, I sprinkled in some legal and compliance sessions, because the technical stuff doesn’t exist in a vacuum.  That, and I find myself being asked to weigh in on accessibility concerns in senior-level conversations more frequently these days.

I may be a glutton for punishment, but whenever I attend a busy conference that has lots of concurrent sessions throughout the day, I try to attend as many as I can…with no breaks in between.  This year, I got to 18 sessions, and it was pretty tiring.  I think it matters that I get the most “bang for the buck” for attending, and it’s important that I don’t keep what I learn all to myself.  So I take notes.  A LOT OF NOTES.  This helps me stay focused when my mind starts to wander, and it may be useful to others.

I hope you find it useful.

Wednesday, March 4 Session Notes

  1. The Implementation of PDF/UA and Standardized Access to PDF Content
  2. Digital Accessibility: 2015 Annual Legal Update
  3. Accessibility at the BBC
  4. Do We Need to Changes the Web Accessibility Game Plan (Redux)?
  5. Real-Time Conversations:  From TTY to Real-Time Text (RTT)
  6. Aiming for Excellence at a Fortune 50 Company (aka TARGET)

Thursday, March 5 Session Notes

  1. CSS, Accessibility and You
  2. Scaling Web Accessibility From Specialist Niche to Business-As-Usual
  3. Web Compliance Evaluation Strategies – All In One
  4. Accessibility in the Web Project Lifecycle
  5. Accessibility in an Agile World
  6. Revised Maturity Model: Case Study of the CIA

Friday, March 6 Session Notes

  1. Choosing an Accessible UI Framework
  2. Evaluating the Accessibility of Your Website:  New Resources and Tools
  3. 7 Lessons from Developing an Accessible HTML5 Video Player
  4. The Digital Accessibility Maturity Model for Measuring Program Success
  5. A Digitally Inclusive Future for Canada’s National Broadcaster
  6. Purchasing Accessible EIT Products:  A Suggested Campus Procurement Process
Categories
Accessibility Technology

The Digital Accessibility Maturity Model for Measuring Program Success

Presenters:  Tim Springer and Jason Megginson from the SSB BART Group

@SSBBARTgroup | View this slide deck online

This was my fourth session at the CSUN conference on Friday, March 6.  The CIA’s session yesterday referred to a different maturity model (the Business Disability Forum’s Accessibility Maturity Model), which piqued my interest and is why I’m here.  I’m beginning to think that the tagline for this conference should be “There’s a session for that.”

What the hell is a maturity model?

  • Defines organizational maturity level in addressing a business problem.
  • DAMM (Digital Accessibility Maturity Model) measures digital accessibility program maturity along a series of dimensions and aspects, to assign them to particular levels

The Digital Accessibility Maturity Model

  • The five levels of DAMM
  • Initial (chaos)
  • Managed (pockets of expertise across the enterprise)
  • Defined (across the enterprise)
  • Quantitatively Managed (repeatable, metrics lead change)
  • Optimizing (reflective, feedback system)
  • DAMM is not a roadmap, but an ongoing business process
  • More maturity != greater conformance
  • Other models require that you must reach a higher level of compliance to achieve a higher CMM level
  • A mature org with a clear grasp of digital accessibility concepts may determine not to conform to a higher level of accessibility

Why a CMM based Maturity Model?

CMM model process improvement adds value to other business areas:

  • Fewer defects
  • Better on-time delivery
  • More likely to be on budget
  • Increased Quality Software Management Productivity Index

There are 10 DAMM Dimensions…

1. GRC (Governance, Risk, Compliance)

  • Looking for higher levels of organizational ownership
  • Aspects:  organizational ownership, governance policy, risk management, compliance program, accessibility program office, monitoring, reporting, record keeping
  • Artifacts:  Org chart, accessibility monitoring plan, accessibility program roles and responsibilities, accessibility project management plan, risk prioritization model, accessibility coverage questionnaire

2. Communication

  • Aspects:  Program comm, internal comm, market comm
  • Artifacts:  Public comm plan, org-wide compliance statement

3. Policy and Standards

  • Aspects:  accessibility policy and standards
  • Artifacts:  digital accessibility policy (some laws require this), technical standards

4. Legal

  • Aspects:  Regulatory process
  • Artifact:  regulatory calendar, regulatory filings, VPATs GPATs (in conjunction with communications)

5. Fiscal Management

  • Aspects:  budget, ROI
  • Artifacts:  central APO budget (persistent from year-to-year), LoB digital accessibility budget guidance, LoB digital accessibility budgets

6. Development

  • Aspects:  development artifacts, roles and responsibilities, user acceptance, pattern library
  • Artifacts:  lifecycle roles and responsibilities, development artifact guide

7. Testing and Validation

  • Aspects:  accessibility training, infrastructure, accessibility testing artifacts
  • Artifacts:  Accessibility testing plan, usability testing, user group profiles, pilot program, assistive technology catalog

8.  Support and Documentation

  • Aspects:  support process, issue handling, accessible documentation
  • Artifacts:  features document, resolution policy, issue submission form

9.  Procurement

  • Aspects:  solicitations, contracts, vendor governance, employee guidance
  • Artifacts:  3rd party compliance policies and reqs, ICT procurement contract template, ICT procurement policy, procurement accessibility email address

10.  Training

  • Aspects:  training, certification, job aids, internal communication, rollout strategy
  • Artifacts:  training plan, internal comm plan, training metrics and trends
Categories
Accessibility Technology

Revised Maturity Model: Case Study of the CIA

Presenter:  Benjamin Wilson from the CIA

This was my sixth session at the CSUN conference on Thursday, March 5.  I don’t think I’ve heard about a maturity model in the accessibility arena yet (they’re fairly common in IT), so I expect this presentation to be educational.  Frankly, I’m a little surprised there are so few people in this session.

Comes to this from a project management, change management and IT perspective.

Why is the CIA Here?

  • Primary goal of the agency is to provide as objective a perspective of the world as we can.  We try to avoid groupthink as much as possible.
  • Goal:  we want to be the Employer of Choice in the Intelligence Community for People with Disabilities
  • Goal:  employees with Disabilities have Independent Access to the information and data needed to accomplish their mission.

It takes 10 years to make culture change, and you should always consider that you’re in year 5

What is a Maturity Model?

Change Management

  • Management:  is there managerial buy-in and commitment to accessibility?
  • Pervasiveness:  how thorough is accessibility being applied in the organization?
  • Competency:  is workforce seeking competency in accessibility and disability awareness?
  • Adoption:  is the workforce actively adopting common tools and solutions?
  • Socialization:  is there employee buy-in and commitment to accessibility?

Capacity Levels in CMM

  • Incomplete > Performed > Managed > Defined

Business Drivers to Change Management

  • Senior commitment
  • Understanding
  • Awareness
  • Stakeholder engagement

2014 Accomplishments

  • CIA Accessibility program chartered
  • New accessibility policy
  • Leadership outreach (CIO annual conference, vendor’s quarterly, DAAC 2014)
  • Piloting processes
  • Communication

Standards & Guidance

  • Organization Process Definition
  • Organizational Training:  AT demos, disability awareness, developer training, IT support training
  • CIA Accessibility Standards:  WCAG 2.0 AA
  • Risk management for remediation:  scoring of applications on a Likert scale of 1-5; a 4.4 indicates a functional level of accessibility.

Programmatics – Key Process Areas

  • Organizational Process Performance
  • Organizational Performance Management
  • Risk Management
  • Acquisition:  vendor self-assess, agency audit contenders
  • Development:  self-assess, report, selective audit
  • Service Delivery
  • Annual report to executive director
  • Business process studies:  2013 accessibility, 2014 improvement of RAS

Acquisition/Development/Service Delivery

  • Objectively evaluate processes and work products
  • Provide Objective Insight

 

 

 

Categories
Accessibility Technology

Accessibility in an Agile World

Presenters:  Jesse Hausler and Cordelia McGee-Tubb from Salesforce.com @jessehausler | @cordeliadillon

This was my fifth session at the CSUN conference on Thursday, March 5.   Interested in this session because of my home institution’s use of Oracle/PeopleSoft, and I expect this session may provide an interesting counterpoint to that platform.

How Agile Fails Accessibility

  • Decentralized product ownership
  • Teams control their own backlog
  • Balance: bugs/accessibility
  • Balance:  feature enhancement / Enhancements
  • Separate accessibility features; mountain of accessibility debt
  • Unless a proper system is put in place, accessibility – under agile – will always take a back seat to the creation of new features

Executive Support

  • “The email” is not the solution.  It can’t do the work that needs to be done.
  • Executives remove blockers and help us build an environment in which accessibility can thrive

Building the Environment – Culture

  • Gain allies and raise awareness.
  • Build the base of passionate people.
  • Spread knowledge about accessibility
  • Build empathy through examples
  • Frame accessibility through your company’s core mission
  • Make it contagious (get other people talking about it)
  • Embed on a scrum team:  teach how to ship accessible features, learn at a micro level how agile works at your company.
  • Knowledge of your company’s brand of agile
  • Success building an accessible feature
  • Prove to the team that it’s not a big hurdle
  • Allies in UX, scrum leadership, development, and quality
  • Path to embed on another, larger, more influential team
  • Create an award that recognizes excellence; publicize winners, generate incentive to build accessible

Tools

  • Create reusable components:  use your contacts to join the appropriate scrum team, guide them toward the development of accessible components
  • 3rd party components:  know which ones are used, gauge level of accessibility, catalogue functionally equivalent alternatives for inaccessible ones, work with stakeholders to enlist accessible alternatives
  • Grassroots marketing campaign:  dropdown / throwdown poster was a classic (lots of great comics in this preso)
  • Take advantage of redesigns:  product redesigns are common, be prepared with a set of accessible, reusable components, beware of redesigns (they could pull out good stuff)
  • Testing Framework
  • Quality Engineering does not normally include accessibility as a traditional part of quality testing.
  • Automation is key to accessibility; build test automation that is specific to your environment.  Opt everyone in, automatically issue test failures where possible, test for patterns that indicate accessibility bugs, perform manual spot checks, track everything.
  • DOM test the simple things (WAVE-testable stuff)

Process

  • How does your company implement a new process?
  • Develop a plan:  problem statement, teams/groups impacted, proposal detail, tracking / success metrics, exception policy, release sign-off process, communication plan
  • Get an executive sponsor:  their main job is to believe in your idea.
  • Example meta process:  define problem > ID impacted parties > engage forum (present proposal, gather feedback) > go/no-go > re-socialize revised proposal, get alignment, final buy-in > go/no-go > visibility to executives > communication and rollout

Summary

  • Cultivate Support
  • Provide Good components
  • Leverage your test framework
  • Institute process change
  • Keep it going

 

Categories
Accessibility Technology

Accessibility in the Web Project Lifecycle

Presenter:  Denis Boudreau

This was my fourth presentation at the CSUN conference on Thursday, March 5.  I’ve known Denis via some conference calls with W3C, and of course I’ve seen him a few times at the CSUN conference.  I’m looking forward to this presentation, but the headache I woke up with this morning is getting worse.  I will try my best to capture this one.

Denis talked a little bit about a project he worked on years ago where there were issues with color contrast in a company rebrand (yellow and light blue on a white background – yech!).  Question the project manager posed to the designer was WHY DIDN’T YOU KNOW THIS?  This story highlights the gaps and communication breakdowns that can occur, even when an organization has committed to accessibility.

Lessons Learned “The Hard Way”

User stories to reflect common issues:

  • “Amy” web accessibility specialist, tasked with assessing redesign against WCAG AA.  Discovers no prior testing has been conducted.  Site launches in two weeks.  LESSON:  dealing with web accessibility at the end of the project lifecycle leads to costly retrofit that could’ve been avoided.
  • “Roy” accessibility coordinator, leads the accessibility task force in his Fortune 100.  Role is making sure they never get sued.  Leadership has not provided clear top-level support.  LESSON:  without clear top-level support from leadership, web acc champions are ultimately bound to be ignored by their peers.
  • “Elena”  QA lead, org is under litigation because their web site was inaccessible to people who are blind.  She built an accessibility checklist.  LESSON:  centralized testing teams who fail to include end users testing in their process are likely to miss significant issues when assessing content.
  • “Chris” business analyst tasked with selecting the next platform for next redesign, has 3 products with VPATs that claim 508 compliance.  Redesign will be done by an offshore development team.  LESSON:  never underestimate the impact of external factors – for they can make or break all efforts towards web accessibility.
  • “Mike” front-end dev, gifted web dev who realized long ago that accessibility was mostly about testing with your keyboard and using native semantic HTML.  Introduced his team to various browser toolbars and everyone now feels confident they have accessibility covered.  LESSON:  developer toolbars, semantic markup and automated testing tools can only get you about 30% of the way towards web accessibility goals.
  • “Julie” Accessibility champion in an organization working toward digital inclusion.  With so much work to do, and so many people asking for help, and so little time to get it all done, she often becomes a bottleneck.  LESSON:  access resources who allow themselves to become bottlenecks give everyone else an excuse to overlook web accessibility.

What do these people have in common

  • They believe they’re doing the right thing
  • pretty much left on their own
  • ultimately bound to fail

Compliance is Overrated

  • No organization has ever been sued over a failed success criterion.
  • What orgs are sued over are the results of poor user experiences.
  • You need to test with real users

Why is Accessibility So Hard?

  • http://webaim.org/projects/practitionersurvey
  • Lack of skills and knowledge
  • Lack of awareness
  • Lack of budget, resources
  • Hinder look, feel, or functionality

I did my own survey…

  • …and asked 100 people what they thought
  • WCAG is NOT a reqs document
  • Excuses:  time, money resources
  • too much documentation, no real-world examples
  • Ruins my creative fun
  • Never seen AT in use (unknown is hard)
  • Don’t know, don’t care
  • Can’t be bothered
  • In the end:  accessibility is not a project with start and end dates, it’s a program.  A lifelong, ongoing program.

Integration in the Lifecycle is Only One Part of the Solution

  • Take ownership
  • Awareness: training & learning, building the business case, sharing the message, etc.
  • Alignment:  Internal and External policies, accessibility support groups, standards and guidelines, etc.
  • Realization:  Best practices, design patterns, style guides, tools, testing methodologies, etc.

Whose Job is It, Anyway?

  • Everyone, BUT…each individual has a set of responsibilities that’s a part of the ecosystem.
  • If people say accessibility is not their job, just ask:  “Is quality a part of your job?”  The answer is yes,  of course.
  • Every stakeholder involved needs to stay alert and pay attention to accessibility at their level in the ecosystem
  • Everyone needs to be accountable.  Share responsibilities.
  • Make subject matter experts in your lifecycle accountable, so the right questions are asked at the right time by the right people.
  • W3C WAI-Engage Wiki:  Distributed Responsibilities Model
  • Successfully planning the right intervention at the right time by the right people will prevent costly errors & oversights
  • Uneducated decisions will yield significant consequences for accessibility later in the project.

Quality is Everyone’s Responsibility

  • Prevent instead of treat
  • Share responsibilities across disciplines
  • Sense of collective ownership
  • Prevent errors & oversights
  • Exceed compliance goals
  • Meet end user’s needs
  • Above all else, accessibility is about building a better quality product

Failing to Plan is Planning to Fail!  Web Accessibility is both the journey and the destination.

 

%d bloggers like this: