All Projects → mgifford → a11y-contracting

mgifford / a11y-contracting

Licence: other
Building Accessibility Best Practices into Contracting

Projects that are alternatives of or similar to a11y-contracting

ckeditor4-plugin-a11ychecker
Accessibility checker for CKEditor 4
Stars: ✭ 17 (-60.47%)
Mutual labels:  accessibility, a11y, wcag
a11y-guidelines
アメーバアクセシビリティガイドライン
Stars: ✭ 61 (+41.86%)
Mutual labels:  accessibility, a11y, wcag
cluse
Sketch Plugin to check and adjust color contrast accessibility with live preview and sliders. Endorsed by Sketch.
Stars: ✭ 54 (+25.58%)
Mutual labels:  accessibility, a11y, wcag
accessibility-ruleset-runner
eBay Accessibility Ruleset Runner automates 20% of WCAG 2.0 AA recommendations, saving time on manual testing.
Stars: ✭ 24 (-44.19%)
Mutual labels:  accessibility, a11y, wcag
AccessSniff
Automated accessibility testing using HTML_Codesniffer (WCAG and Section508)
Stars: ✭ 84 (+95.35%)
Mutual labels:  accessibility, a11y, wcag
alfa
♿ Suite of open and standards-based tools for performing reliable accessibility conformance testing at scale
Stars: ✭ 75 (+74.42%)
Mutual labels:  accessibility, a11y, wcag
eufemia
DNB Design System
Stars: ✭ 38 (-11.63%)
Mutual labels:  accessibility, a11y, wcag
chusho
A library of bare & accessible components and tools for Vue.js 3
Stars: ✭ 47 (+9.3%)
Mutual labels:  accessibility, a11y, wcag
enabler
✋ Accessibility analyzer for your frontend.
Stars: ✭ 19 (-55.81%)
Mutual labels:  accessibility, a11y, wcag
accessibility-testing-tools
A collection of useful tools for accessibility testing and debugging in the browser, online and desktop
Stars: ✭ 18 (-58.14%)
Mutual labels:  accessibility, a11y, wcag
Accessibility
A repo to organize the guidelines and best practices for accessibility at 18f.
Stars: ✭ 269 (+525.58%)
Mutual labels:  accessibility, best-practices, a11y
a11y-checker
Identifies accessibility issues in HTML markup.
Stars: ✭ 103 (+139.53%)
Mutual labels:  accessibility, a11y, wcag
accessibility-resources
Screen reader and WCAG testing resources to maintain a consistent approach to testing and documenting behaviour.
Stars: ✭ 25 (-41.86%)
Mutual labels:  accessibility, a11y
open-source-contracting
Providing example language for contracts which work with open-source software and explicitly want to encourage it's growth and development.
Stars: ✭ 44 (+2.33%)
Mutual labels:  procurement, contracting
vue-focus-loop
Vue component that helps you to to trap focus in an element.
Stars: ✭ 23 (-46.51%)
Mutual labels:  accessibility, a11y
agnostic-axe
Framework agnostic accessibility reporter, powered by axe-core
Stars: ✭ 80 (+86.05%)
Mutual labels:  accessibility, a11y
accessibility-resources
A curated list of accessibility resources
Stars: ✭ 66 (+53.49%)
Mutual labels:  accessibility, a11y
playwright-lighthouse
🎭: Playwright Lighthouse Audit
Stars: ✭ 120 (+179.07%)
Mutual labels:  accessibility, best-practices
openacr
OpenACR is a digital native Accessibility Conformance Report (ACR). The initial development is based on Section 508 requirements. The main goal is to be able to compare the accessibility claims of digital products and services. A structured, self-validated, machine-readable documentation will provide for this.
Stars: ✭ 61 (+41.86%)
Mutual labels:  accessibility, a11y
cauldron
cauldron.dequelabs.com/
Stars: ✭ 50 (+16.28%)
Mutual labels:  accessibility, a11y

Accessibility Contracting Best Practices

Building Accessibility Best Practices into Contracting

Most RFPs that talk about accessibility include something like:

We require that all purchases be accessible according to the Web Accessibility Initiative 
(WAI) Web Content Accessibility Guidelines 2.0 AA. 

or

All content, interfaces, and navigation elements to be used for this project must be 
compliant with Web Accessibility Initiative (WAI) Web Content Accessibility Guidelines 2.0 AA. 
Compliance means that a person with a disability can percieve, operate and understand the 
interface the same as a person without a disability.

Concerns

  • Don't ask that a vendor commit to making a site meet a set accessibility target if there isn't a clearly defined set of deliverables or a flexible budget.
  • Ensure that whoever is driving the design & functionality requirements for the site have a good grounding in accessibility. Decisions made by the client often meet other organizational needs. If the person deciding on behalf of the client isn't aware of accessibility implications of their decisions then it may affect the delivery of the end product.

Don't include in RFP

  • Any specific requirements to use Web Accessibility Initiatives – Accessible Rich Internet Applications (“WAI-ARIA”) to further enhance accessibility. If used properly it will, but it doesn't add anything beyond WCAG 2.0 AA above and can destract from accessibility if it is implemented poorly.

10 Steps for Accessible IT Procurement

Based roughly on Smart Practices for Addressing Accessibility in Vendor Contracts

  1. Set up an internal Accessibility Policy
  2. List goals (like WCAG 2.1 AA), your internal policy as well as any government regulations you must comply with
  3. Ask for details on how the vendor will meet accessibility goals. Make sure these do not rely exclusively on automated tests
  4. Make sure that your RFP is accessible and that the proposals are also created in an accessible format
  5. Clients should have people knowledgeable about accessibility as part of the procurement process and should be asking questions about the process to demonstrate that this is important
  6. Not all products have a VPAT. Most VPATs are mostly marketing. If a VPAT is produced by a recognized 3rd party, it can provide some useful insights. It is the client's responsibility to ensure that they understand it, so ask questions
  7. Make sure that you have understanding about the contract. There are other examples here of what you might want to consider
  8. Do an independent evaluation. If you are hiring a firm to build a customized solution, make sure you test it before it is launched. The vendor should know this will happen.
  9. See that you have processes in place to escalate accessibility problems when they come up. There will be new barriers identified as people start using the technology, make sure there are processes in place to deal with them quickly.
  10. Set up a monitoring agreement with a 3rd party to see that you get informed of new issues when they come up

5 simple steps for clients to evaluate vendors

  1. Evaluate the vendor's site with something like to see basic errors https://wave.webaim.org
  2. Ask about their experience working with web accessibility?
  3. Determine how accessibility fits as part of their QA process?
  4. Ask when they address accessibility in their development process?
  5. Learn about training opportunities for your staff?

Questions for the Procurer (Client):

  • Is there an established accessibility procurement policy or a procurement policy where accessibility is explicitly mentioned?
  • The procurement contract should include language that specifically documents how satisfactory progress on accessibility will be measured.
  • If the product is currently accessible, the contract should include language that assures continued accessibility as the product is updated.
  • Is there a 3rd party audit built into procurment?
  • Do your boiler-plate contracts state that your organization owns the IP generated? If you are using open-source software, do you explicitly support fixing problems (or even reporting) problems in the source libraries?
  • Do you use a "work for hire" policy which traps all intellectual property done with institution money/time? Is it possible to explicitly exempt open-source contributions or encourage contributions?
  • How are you planning to use the product?
  • How are Voluntary Product Accessibility Template (VPAT)s seen & evaluated within your institution?
  • Do they have an [Accessibility Statement(https://github.com/accessibility/Accessibility-Statement/) or Accessibility Policy - if so it should be included.

Internal expertise

  • Is there a Accessible Technology Initiative (ATI) person in your organization who can help ensure consistent implementation of Accessible ICT procurement procedures?
  • Who on the organization's side is responsible for evaluating accessibility of the product delivered?
  • Who oversees the review of ICT accessibility compliance documentation?
  • Who coordinates with ICT vendors to resolve issues with accessibility support or documentation?
  • Who is the primary contact for questions regarding Accessible ICT procurement?
  • Does someone coordinate the delivery of Accessible ICT procurement training programs in your institution?
  • Has Vendor inability to provide accessible products has affected purchasing decisions? Who maintains a success/failure record in your institution?
  • Will someone be able and willing to submit problems to the product's issue tracking system?
  • When a product has a fix for a problem that you have identified, who will be able to verify the fix?
  • Who is maintaining the list of what assistive technology is supported?
  • Who is the primary accessibility lead within our organization?

In section listing the various questions that Vendors need to respond to, include:

Product

  • Are all interfaces (both for administrators and end-users) that are part of your product compliant with WCAG 2.0 AA?
  • Does this product meet any targets for ATAG 2.0 AA, Part B?
  • Who will pay to remediate any necessary fixes after purchase?
  • If your product is not WCAG 2.0 AA compliant, do you have a roadmap to make your product fully compliant? If so, include your roadmap.
  • If we find that there are changes that need to be made to web/mobile interfaces/apps, what guarantee can we have that these will be implemented to our satisfaction prior to go-live/going forward?
  • If you have created a VPAT, is it prepared by a 3rd party?
  • What standards are you using to evaluate accessibility?
  • How are accessibility features documented? Are they discoverable by the user?
  • Is this product being used by accessibility focused organizations and are there any reviews by them.
  • WCAG related accessibility barriers are categorized as bugs; not feature requests

Process

  • Describe your accessibility conformance testing process.
  • Describe measures you've taken to ensoure your IT products or services are accessible.
  • Is there an open issue queue of known accessibility issues for the IT product?
  • If there are known barriers for users, vendors should be asked to make a commitment to improving accessibility over a specified timeline.
  • Has your team ever worked with Accessibility as a functional requirement?
  • What are your company's internal standards for developing with accessibility in mind?
  • Does your company have a road map for accessibility going forward? If so, can you give us a general outline (goals / milestones)?
  • Have you tested and/or developed your mobile apps (especially iOS) with accessibility in mind?
  • What automated tools do developers & designers use to evaluate their work?
  • Describe the steps you take for manual testing of your interface.
  • How are you keeping pace with the changes in Assistive Technology?
  • What training do you give to your staff to see that inclusion is understood?

Experience

  • Do you have clients who require web accessibility? If so, in outline, how are they ensuring your product meets their requirement?
  • Do you do testing with users with disabilities? If so, can you explain the process and identify, roughly, the range of disabilities and access technologies used?
  • What experience do developers on your team have coding for accessibility?
  • Have your developers contributed to any open-source accessibility work you could link to?
  • How do your developers and designers stay up-to-date with best practices with web accessibility?
  • What resources do you refer to for information about addressing accessibility?
  • Have you adopted a Policy-driven Adoption for Accessibility (PDAA) framework to demonstrate the extent to which your organization has implemented accessibility best practices?
  • Does your website & proposal reflect knowledge of accessibility? How well does the vendor site score with automated tests like http://wave.webaim.org/ or https://tenon.io/

Related Presentations

Useful Links

Government

North America

Europe

Education

Business / NGO / Other

Note that the project description data, including the texts, logos, images, and/or trademarks, for each open source project belongs to its rightful owner. If you wish to add or remove any projects, please contact us at [email protected].