From my CSUN 2011 presentation
A lecture style session discussing ways to approach management of accessibility compliance at the enterprise level including project/ program management and procurement.
Managing Accessibility Compliance in the Enterprise
1. Managing Accessibility Compliance in the Enterprise Karl Groves Director of Training, Deque Systems Phone: 443-517-9280 E-mail: karl.groves@deque.com Twitter: @karlgroves
2. Download These Slides Shortened URL: http://goo.gl/7UsEF Long Form URL: http://www.slideshare.net/karlgroves/managing-accessibility-compliance
3. Agenda Defining the problem Solving the Problem 20 Questions: or, Gauging Organizational Maturity Managing Compliance Project Management Approaches Waterfall Agile Training Center of Excellence Recap & Questions
5. Defining the Problem Objective: Understand the ways in which accessibility is often mishandled in large organizations, thus leading to risk exposure
6. Defining the Problem Accessibility compliance is often backwards Testing & compliance efforts often happen after the fact Post-deployment remediation is often expensive, time-consuming, and incapable of addressing high impact issues This damages profitability, timelines, and quality
7. Defining the Problem Accessibility is often not part of the process Should be included in all phases of the lifecycle Planning Requirements Procurement/ Design & Development Release Maintenance
8. Defining the Problem Staff often lack training on accessibility Executives Human Resources Project Managers Developers Content Creators QA
9. Defining the Problem Accessibility policy & procedure not formalized Not part of ELC/ SDLC No formal conformance criteria No teeth to acceptance process No enterprise tools provided to staff
11. Gauging Organizational Maturity Where does the organization stand nowwith respect to Accessibility Policy & Procedure? This gives us our path moving forward.
17. Gauging Organizational Maturity Does language exist in your procurement/ specification development documents which discuss accessibility compliance? If so, is it specific enough to be followed
18. Gauging Organizational Maturity Are deliverables validated for accessibility before acceptance? Is code validated for accessibility before acceptance into source control?
27. Gauging Organizational Maturity What formal training does the typical developer have in accessibility? What formal training does the typical QA tester have in accessibility?
33. 55% of the skills questions were answered incorrectly across all 4 areas
34. 23% of the respondents had some formal training in accessibility
35. 22% had training* in the workplace on Accessibility (not formal training)
36. 21% seek out accessibility knowledge online through web sites and blogs
37. 3% of those tested attended an accessibility related event
38.
39. Managing Compliance How can we address the shortcomings found in our organization’s level of maturity with regard to accessibility?
40. Managing Compliance: High Level Train, train, train Institutionalize conformance Plan compliance a head of time Include a SME throughout all project phases Monitor compliance at all phases Implement Center of Excellence Prevention is preferable to inspection & rework. Remediation can add up to 40% more time to front-end development if not done right in the first place
41. Remediation vs. Doing it Right Avg. cost per defect = (num of devs * num of hours) * cost per dev per hour -------------------------------------------------- (number of fixed defects) Some estimates in QA community calculate cost around $500 per defect to find & fix defects and deploy remediated code Dependent upon #of bugs, etc.
45. Planning Phase Determine what risk is involved re: accessibility Determine the overall impact accessibility may have on project timeline Determine whether any extra funding or resources are needed for accessibility Include accessibility assets needed for project Determine what accessibility related activities are necessary in each phase
46. Requirements Phase Identify accessibility stakeholders For each feature/ technology in use, determine what standards and guidelines will apply Include typical use cases/ user stories to generate accessibility requirements
47. Procurement Investigate what conformance requirements exist for deliverable Communicate this in all solicitations Research available market offerings Determine which product/ service offers highest level of compliance while fitting business need Validate vendor claims of conformance, they will often be inaccurate or incomplete Ensure final award documents cite conformance requirements
48. Design Phase Utilize deliverables from planning & requirements phases to inform design phase Revisit/ revise conformance criteria based on technologies in use Validate design prototypes and comps with stakeholders and SMEs Audit functional mockups for accessibility Utilize formal best practices to gauge compliance
49. Development Phase Get ahead of accessibility issues. This is the last viable chance to prevent problems Revisit/ revise conformance criteria based on technologies in use Perform iterative testing as system is developed Developers should test code as they develop, just as they would for browser compatibility
50. Testing Thorough testing required Test against formal standard with well-defined conformance criteria Ensure testing involves functional performance with assistive technologies
51. Deployment Phase Ensure system is deployed with any accessibility-related configuration in place
52. Maintenance Phase Provide a method to identify and track accessibility-related problems (pref. as bugs) Assign appropriate priority to issues
53. Milestone 1 Milestone 2 Milestone 3 Milestone 4A Milestone 4B Milestone 5 Work ProductComponent Applicable Provision Evaluation Initial Final Update Update Accessibility Risk Information Document Initial Final Update Update Initial Final Update Accessibility Compliance Approach Initial Final Update Update Integration Plan forAccessible Support Initial Final Final Initial Accessibility Test Plan Accessibility Test Results Identify the Applicable 508 Provision Create a Test Plan Identify 508 Issuesand Make Corrections Enterprise Life Cycle (ELC) Section 508 Work Product - to - Milestone Cross-Reference Matrix
57. Agile vs. Waterfall Both methodologies have: Planning Requirements Design Develop Implementation Difference is in approach No difference regarding accessibility
58. Agile - Planning Develop accessibility user stories “I want to be able to access audio description for online videos” “I want to be able to compare products”…”using a screen reader” Identify disabled Customer Representative “Customer collaborationover contract negotiation” (Agile Manifesto)
59. Agile – Planning Based on features under development this cycle: Identify any applicable standards. For those standards, identify conformance criteria For each conformance criteria, identify best practices to develop requirements Include these requirements in Definition of Done
60. Agile - Development Developers should create accessibility tests during test development Developers should utilize automated testing (inc. tools like FireEyes) during development prior to committing changes
61. Agile - Development Ensure any unmet accessibility requirements are put into sprint backlog for reinclusion next iteration
65. Benefits of Training Addresses disparities in level of understanding Addresses inaccuracies/ deficiencies in understanding Reduces risk of non-compliant interfaces & content Avoids costly post release remediation Protects project timelines and budgets
66. Training Philosophy Train people to understand disabilities A firm grasp of “Why” can always lead you to discover “how”. Technology is always changing. Challenges faced by disabled users do not change. Train people to understand their specific impact on end users
67. Training All involved in design & dev, plus HR & execs should get high level understanding of: Laws Standards Understanding Disability
69. Training Human Resources Skill set(s) to look for in future applicants Training requirements for current staff
70. Training Procurement Legal implications of accessibility compliance How different technologies impact accessibility How, when, and which standards apply
71. Training Project Management Understanding requirements & how to define them Integrating accessibility into lifecycle: what & where
73. Training Developers Specific BPs relating to production of accessible interfaces Specific advanced techniques based on technologies under development.
74. Training Content Creators Specific BPs relating to production of accessible content Techniques & Procedures on use of content creation tools (i.e. content management systems) so accessible output is ensured
75. Training QA Need to understand how to test for accessibility Need to understand how to use accessibility testing tools & interpret their output
77. Center of Excellence: What it is Centralized location for knowledge, training, support, and expertise in accessibility. Provides communication between knowledge domains Develops, maintains, and shares accessibility resources, and assets Sample deliverables, test plans, conformance guides, code samples, etc.
78. COE: The Promise Support for individuals and enterprise Standards for consistent implementation Training to improve individual and enterprise execution Measurements to the expectation Governance for consistent implementation by the agency and contractors
79. COE: Support Design Support Prototype Validation Development Support Accessibility User Stories Customer Advocate Subject matter expertise Testing Support Testing/ Conformance Continuous Monitoring Use Case/ Usability Test Support
80. COE: Standards Broad, Organizational Standards Interpretation of Ind. Standards Development Guides Global Testing to determine areas of improvement
81. COE: Training Establish an agency/corporate curriculum Testing/ Conformance guides based on technologies in use New hire assets
82. COE: Measurements Dashboard reporting throughout all levels of the enterprise Establish your benchmark and measure improvements Assist PM in measuring success Gather metrics
83. COE: Governance Ensure consistent contract language Ensure compliance of deliverables by vendors Gatekeeper to acceptance/ release/ milestone exit Rules which are not enforced don’t get followed
85. Recap The Problem Accessibility Compliance is Backwards Accessibility Not Part of the Process Staff are not trained Accessibility Policy & Procedure not formalized The Solution Train, train, train Institutionalize conformance Plan compliance Include a SME throughout all project phases Monitor compliance Implement Center of Excellence
If there is no formal program in place, chances are accessibility of your systems will be low
Often, the answer is “nobody”.In cases where such a person exists, they might not have a firm grasp of what compliance isHuman Resources/ EEO staffUX team
The PMO is the best starting point for making sure accessibility progress is tracked during projects – especially new ones.“No PMO” means a formalized process for accessibility compliance may not exist.
An established SDLC may (hopefully) contain touch points during the various phases where accessibility can be verified and tested for.If not, at the very least it gives us place to put it.
This is sort of the “proof in the pudding”. You can nearly guarantee that if it isn’t in the SDLC then it is unlikely that the company will have any meaningful accessibility program.After all, if it isn’t formalized there, then where else can it be formalized?
Any time an IT product/ service is developed or procured, various specific requirements are included in the procurement and/ or requirements documents. If these documents do not discuss the accessibility requirements, then accessibility is not likely to be a consideration for the developers (and the final deliverable will not be compliant)
No control over what gets in means anything gets in.Typically organizations validate for security, functional performance, but not accessibility.
Most developers are self-taught in their trade.Formal training (at computer schools, college comp. sci. programs, etc.) often do not discuss accessibility to any meaningful degreeTherefore if the company doesn’t do it, it doesn’t happen.
Typically, only web accessibility has much attention by customers.Or, they assume software to be inherently accessibleOr, they don’t give much concern over other technologies
The more that a website/web application diverges from standard HTML & CSS, the more likely that developers are ill-prepared to address accessibilityAlso, the more likely that they’ll be given to misunderstanding the facts regarding accessibility.
Typically none of these will have strong accessibility auditing experience.Developers’ jobs should include testing their code, therefore they should be doing *some* testing for accessibility. However, unless they’re well educated in accessibility they probably don’t know much about it and therefore don’t know how to test for it.QA staff generally don’t have much accessibility knowledge – but they should.
Use of free tools/toolbars/ plugins and out of date products (AccVerify, InFocus, A-Prompt, Bobby/Watchfire) indicates a lack of formal accessibility process in the org. and lack of knowledge in this domain.(At the very least, it betrays a lack of organizational maturity with respect to accessibility)
If they use an enterprise-class tool (AMP, Compliance Sherriff, Rational AppScan, Worldspace): Have they had any formal training in how to use the product?If they have not been trained on the product, there’s a strong chance they’re not getting much benefit from using it. They may have even given up on the tool altogether.
Lacking a documented methodology will mean that results may be: InaccurateIncompleteNot repeatable during Regression
“None”Obviously BadWCAGWhat version?What Level/ Priority?Section 508What technical provisions? Do they test for 1194.31?(Gov’t/ Integrators) If they develop Flash/ Flex and don’t test for 1194.21, they don’t understand accessibility
Most developers are self-taught in their trade.Formal training (at computer schools, college comp. sci. programs, etc.) often do not discuss accessibility to any meaningful degreeTherefore if the company doesn’t do it, it doesn’t happen.
If so, which assistive technologies?Use of free AT or simulators is not likely to yield valid results Use of only one AT is not considered complete coverage. What is their level of proficiency with these assistive technologies?Less than “daily use” is considered equivalent to “not proficient”
Each provision of a given standard needs documented conformance criteriaOtherwise subjective interpretation occurs.Test results will be:IncompleteInvalidNot Repeatable
The single best way to measure accessibility is to test with users with disabilities.Beware that users who are highly technical are not good representations of typical users Success with one user does not correlate to success with all usersOne guy with JAWS being successful at a task is not a blanket blessing upon the entire system
Fact: Nobody has ever been sued because they did not meet technical conformance criteria.They were sued because of functional performance issuesTechnical conformance is meant as a way to meet functional performance (and to prosecute/ defend the system)
Fundamentally, the primary reason why accessibility isn’t more well-placed in the enterprise is because
The bottom end of estimates of cost-per-defect is about $500 per bug. This amount is mostly dependent on two factors: time to fix the average bug and the number of bugs fixed. Less bugs fixed will raise the cost-per-bug, as the typical case is that developers can (and will) be able to fix multiple bugs of the same type rather quickly.The thing to take away from this is the fact that this is time and money that does not need to be spent. If all staff are properly trained and accessibility is properly integrated into the development lifecycle, the project budget and timeline are protected from this unnecessary expense
During all projects dealing with the purchase, development, or implementation of a software or web project, accessibility needs to be included in every stage – from planning to disposition. For instance, during the planning phase accessibility stakeholders must be identified and included. Later these stakeholders are able to assist in requirements analysis and development. During the design and development phases, accessibility requirements must be included and accessibility testing should be included in the testing phase. Finally, accessibility should be included into the deployment and maintenance phases to ensure as the project is released and maintained.
Testing for accessibility compliance is vital for determining the status of compliance for both the individual projects of an organization as well as the organization as a whole. Without thorough testing, any statements relating to the organization’s compliance will be based purely on conjecture. It is only through the implementation of testing and auditing processes that the necessary data can be captured to understand the organization’s compliance status. Organizations should develop detailed policies with respect to their accessibility compliance and part of these policies should outline the criteria against which systems will be tested and how that criterion will be tested. The organization should then develop or purchase the necessary tools or services to perform that testing.
When it comes to accessibility during project management, there is really little difference. In both cases, you will want to ensure that accessibility has been included in all phases it is appropriate to do so.The primary difference comes with how this is managed. In a waterfall model, accessibility is handled like all other traits of the product: everything is planned as much as possible up front, whereas in an Agile model only those accessibility concerns during this iteration are relevant.
Accessibility user stories can help ensure accessibility is kept in mind when determining what will be included in the iteration. In the first example, we see a user story that may result in an entirely new feature (or characteristic of a feature) that probably would not exist were it not for the consideration of accessibility during story development. In the second case, we see a modification or extension of a typical user story which could have a big impact on how that feature evolves. “Everyone” visiting the site would benefit from the ability to compare colleges. However, the “using a screen reader” part may help steer the characteristics of how the college-comparison feature is designed & developed.Identifying a Customer Representative who is disabled (or is a SME on accessibility) can be an invaluable resource during development cycle. Team members can turn to the Customer Representative with questions regarding how the goal(s) in the user story can be met – in an accessible manner.
Based on features under development this cycle:Identify any applicable standards. Once the team has come to a determination of what features are going to be included in this iteration, it is vital to then come to a determination of which standards are applicable to those features. The company itself may have determined which standards it is going to adhere to (such as WCAG 1.0, WCAG 2.0, Section 508, or something else). However, when it comes to this iteration, not all of the items in the standard will apply. For example, imagine our company has chosen WCAG 2.0. If there are no features which include audio or video during this iteration, then we don’t need to worry about Guideline 2 of WCAG 2.0 (Time Based Media). So the first step here is to determine which standards and provisions of those standards are applicable to the work we’re doing in this iteration.For those standards, identify conformance criteria. Each provision of our chosen standard can further be broken down into conformance criteria. For example, WCAG 2.0 Success Criterion 1.1.1 (Non-text content) can be broken down into several conformance criteria. For example “All images must have alternate text”, “All alternate text for images should be informative”, and so on. (Generally the conformance criteria can be borrowed by or born directly from the standard language itself. See: http://www.w3.org/TR/UNDERSTANDING-WCAG20/text-equiv-all.html_For each conformance criteria, identify best practices to develop requirements. Once we know what the conformance criteria are known, we can then draw together a list of best practices aimed at meeting the conformance criteria. Again, in consideration of WCAG 2.0 1.1.1, there could be as many as 3-dozen best practices – however, not all 36 will apply in this iteration, depending upon what features are under development.Note: this probably sounds like a lot of work to be doing – the likes of which appears counter to the spirit of what Agile is all about. The reality, however, is that much of the work above can be done at the organization level once and can exist as internal best practices from which to draw when working on this iteration’s features.Include these requirements in Definition of Done. Once we have our best practices outlined, we know what it takes to determine what “Done” means. In many cases, our “Done” list won’t look too different than it does today. It will still include things like “All Code Checked In”, “All Unit Tests Passed”, etc. But what might be different is what it takes to get there. In other words, our list of tests may be different. Or, on the other hand, we could actually include a new line “All Accessibility Tests Passed” or “All disabled user test cases passed”. However you as a company choose to approach this, just be sure that you keep in mind that if accessibility isn’t part of what you as the PM considers done, it won’t be what the developer thinks of as done, either.
During the active development during each iteration, developers will create tests to verify the code is working and meets the requirements for the User Story. In the process of creating these tests, the developers should be sure to include any applicable accessibility tests as well.We recognize that accessibility is primarily a user-interface concern and therefore developers may not be developing unit tests for the UI. However, it is up to the team to decide whether any tests can be included. For instance, if you’re testing the code that retrieves a video file from a database, the test could be extended to include a verification that the related SMIL or TimedText file is pulled as well.In cases where actual Unit Tests aren’t being written, developers should still utilize some other form of testing. For example, a developer could utilize FireEyes to test for accessibility. Automated testing, in and of itself, is not sufficient for making definitive judgments regarding accessibility, but this should be regarded as bare minimum before committing changes.
Accessibility is not unlike any other requirements. There will invariably be some accessibility-related requirements which just can’t make it through in this iteration. So, like any other unmet requirement, we place unmet accessibility items into the backlog for inclusion during the next sprint.
Remediation of accessibility issues should take into consideration how long it will take to fix a bug and what sort of positive impact fixing the bug will have on users with disabilities. We can infer from the image in this slide that issues which can be fixed fast and have high positive impact should be the ones which get our more immediate attention. Issues which take a long time to fix and don’t really make much impact should be deferred for later – with the understanding that all issues deserve consideration.Although this image shows only two axes: Time and Impact, there is also one more which should be considered, which is Volume. In this scenario, we’ll want to ensure that we fix repetitive pattern issues en masse. This provides a level of efficiency which will assist in mitigating risk (for the pattern violations) rather quickly. Either way, the image above gets to the point rather well.
In order for all relevant parties to understand their roles in ensuring accessibility in the enterprise, they must be trained. Executives, managers, project managers, procurement staff, human resources personnel and even most web & software developers typically do not get significant training in accessibility compliance. Even most computer science or human factors programs in college do not offer detailed instruction in development of accessible systems. Therefore the inclusion of new accessibility-related requirements into their duties will result in failure unless they have been sufficiently trained in what their duties are with respect to accessibility.