Managing Accessibility Compliance in the Enterprise

Editor's Notes

• #12: If there is no formal program in place, chances are accessibility of your systems will be low
• #13: 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
• #14: 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.
• #15: 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.
• #16: 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?
• #17: 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)
• #18: No control over what gets in means anything gets in.Typically organizations validate for security, functional performance, but not accessibility.
• #19: 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.
• #20: 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
• #21: 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.
• #22: 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.
• #23: 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)
• #24: 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.
• #25: Lacking a documented methodology will mean that results may be: InaccurateIncompleteNot repeatable during Regression
• #26: “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
• #27: 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.
• #28: 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”
• #29: Each provision of a given standard needs documented conformance criteriaOtherwise subjective interpretation occurs.Test results will be:IncompleteInvalidNot Repeatable
• #30: 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
• #31: 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)
• #35: Fundamentally, the primary reason why accessibility isn’t more well-placed in the enterprise is because
• #36: 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
• #37: 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.
• #45: 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.
• #52: 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.
• #53: 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.
• #54: 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.
• #55: 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.
• #56: 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.
• #58: 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.
• #59: 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.