search.json

[
  
    {
      "title"    : "Five reasons to get excited about governmentwide Section 508 assessment criteria",
      "url"      : "/posts/five-reasons-to-get-excited-about-governmentwide-section-508-assessment-criteria",
      "content"  : "Five reasons to get excited about governmentwide Section 508 assessment criteriaMike had this article published with the Federal News Network celebrating the approach taken by the Office of Management and Budget, U.S. Department of Justice and the GSA to collect accessibility information from government agencies.Seeing results every six months will also be so important to be able to track progress on meeting the Seciton 508 goals, but also achieving the government's Diversity, Equity, Inclusion and Accessibility (DEIA) goals.",
      "date"     : "2023-08-08 18:00:00 +0000"
    },
  
    {
      "title"    : "Treat accessibility issues as bugs, not feature requests",
      "url"      : "/posts/fix-accessibility-bugs",
      "content"  : "Treat accessibility issues as bugs, not feature requestsMike had this article published with GitHub's ReadME Project looking back over what worked with Drupal, and how it could apply to more open source projects.Drupal is probably the most accessible content management system in the world. This didn't happen over night, and it has taken the input of hundreds of people. Still there are other software communities that can learn from this to make their code more accessible.",
      "date"     : "2023-08-08 16:00:00 +0000"
    },
  
    {
      "title"    : "How OMB can improve .gov accessibility",
      "url"      : "/posts/how-omb-can-improve-gov-accessibility",
      "content"  : "How OMB can improve .gov accessibilityMike had this article published with the Federal News Network on how the USA government can learn from best practices adopted in Europe with the Web Accessibility Directive.There is such a great opportunity to learn from and build on the work done by the European Commission. Right now they are leading the world in digital accessibility.",
      "date"     : "2023-05-05 16:00:00 +0000"
    },
  
    {
      "title"    : "Daniel Mundra: Diving into Drupal",
      "url"      : "/posts/daniel-mundra-diving-into-drupal",
      "content"  : "We spoke to CivicActioner Daniel Mundra, Associate Director of Drupal, aboutthe benefits of Drupal, community contributions, and why working atCivicActions has been so rewarding for him . He is among a team of 60+ Drupalengineers with nearly 20 Acquia certifications and 20+ edX a11y(Accessibility) certifications.CivicActions is known for our Drupal expertise. To you, why is Drupal suchan important tool in the work that we do for our government clients?Drupal is a complex tool but it is the best tool to help deliver complexconcepts for our government clients. Drupal also delivers for our clientswhile still being free, open source, having a growing community, and also notafraid to change/adapt. I don't believe other similar products could check allthose boxes.I have been working with Drupal for 12+ years, first with Drupal version 6 andnow with 10. Since my early days, Drupal has been a veritable Swiss army knifefor web development. It helped me deliver a lot of value to users in a quickamount of time. Earlier I would produce many sites with a lot of modules butnot consider the maintenance costs, reliability you get with writing tests,giving back to the community, and so on. It left my clients with a functionalsite but a maintenance burden. Nowadays I focus more on contributing back,writing more tests, reducing maintenance burden and thinking of long termsolutions than quicker output of sites. Just like how the Drupal platform andcommunity has evolved, so have I. Drupal has given me the space to do that andI am grateful for that.What are some community contributions to Drupal from your team that you areespecially proud of?CivicActions contributes quite a bit to Drupal. Last year CivicActions wascredited with contributing 90+ contributions and that is only growing. I amparticularly proud of the modules we are adding to the community, like MediaLink Enhancements (from Cameron Prince), Google Programmable Search JSON API(from Timo Zura and Sam Lerner), and recently Content Model Documentation (from Steve Wirt).You are very passionate about accessibility — why is accessibility soimportant to you and how do you work to make projects more accessible atCivicActions?Accessibility is important to me because to truly be human centered we have tomake technology accessible to all. The primary ways I work to make projectsmore accessible is by first building from the beginning with accessibility inmind. The second way is to add layers of accessibility testing to ensure thesite remains accessible. Layers like automated testing, manual testing withkeyboards/screen readers, and testing with disabled users (when possible).Accessibility is a long term commitment and I can say that at CivicActions weare all contributing to that and we are making a difference.What initially drew you to a career in civic tech, particularly atCivicActions?After spending 10 years working in higher education, in particular as an in-house developer for the University of Oregon, I wanted a change. As theuniversity was going away from in-house development, I wanted to continuegrowing my skills while still supporting similar mission-driven organizations.I found both at CivicActions.What is the most rewarding part of your job?Being able to give back to the community and also take part in the companyoutside of the project. I am an associate director now but I wouldn't havebeen able to reach that role without the support of everyone at CivicActions.They made space for me to take part in company activities like OKRs, guidebookupdates, accessibility practice area, and so on. I am successful because ofthe culture of the team to make space and make most parts of the companyaccessible to discussion, debate and continuous improvement.Any advice for someone looking to follow a similar career trajectory?Ask questions and get involved where you can, either at the company you workfor or in your local community. Find that company and community that energizesyou and bring your whole self to them.On a lighter note, what is a fun fact that people may not know about you?I like statistics so much that for 3 years I was the official statistician forthe Oregon Cricket League. Lots of data entry and review but I was able to seehow local players and teams evolved.Daniel Mundra: Diving into Drupal was originally published inCivicActions on Medium, where people arecontinuing the conversation by highlighting and responding to this story.",
      "date"     : "2023-04-10 16:00:00 +0000"
    },
  
    {
      "title"    : "Helping disabled Veterans Check-In: Designing an Accessibility Map",
      "url"      : "/posts/helping-disabled-veterans-check-in-designing-an-accessibility-map",
      "content"  : "A note on language: We're using both people-first language ("a person with adisability") and identity-first language ("disabled person"). We recognizeboth are valid and advocated for within the disability community."We lost our vision due to our service…my vision gets blurry," says a Veteranover Zoom during a user research session.We were testing new designs for a web-based app helping Veterans check into amedical appointment.This Veteran's experience is not uncommon: about 30% of Veterans live with adisability (but that number is likely much higher due to military culture).Almost 7,000 Veterans become newly blind or visually impaired every year. Anddisabilities can vary in type and severity — the most common of which includehearing loss, post-traumatic stress disorder (PTSD), scars, back and neckpain, and migraines. Figure 1: A fewdays before an appointment, a Veteran receives an SMS text with a link tostart pre-check-in. After selecting the link, the Veteran sees the login page(first image). When they complete pre-check-in, they see the submission page(second image). Figure 2: When theVeteran arrives on the day of their appointment, a poster with instructions tocheck-in is placed in the facility. The Veteran scans the QR code or texts'5309' to check into their appointment using their phone. The Medical SupportAssistant (MSA) receives a notification that the Veteran has checked-in totheir appointment. The Veteran waits until called in.Checking into a medical appointment with a smartphone has barriersFor example, it requires a Veteran to:  Own a phone (or have access to one)  See the check-in poster at the facility  Have reasonable tech-savviness to use SMS or a QR code  Understand the steps within a reasonably short time-frame (which can be difficult for some Veterans with cognitive disability or PTSD)  We wanted to design digital and non-digital solutions that helped make itmore usable for disabled Veterans to check into medical appointments.But we had a lot of questions.  Are we able to design for the range of types and severity of disabilities?  Would some solutions only benefit some Veterans, while introducing barriers to others?  How do we decide on those trade-offs?We created an Accessibility Use Case MapAn accessibility use case map is a framework to evaluate proposed solutionsacross multiple different types of disabilities affecting Veterans. Weconsidered both digital and non-digital solutions for each phase of the check-in process.A spreadsheet makes it accessibleAs we note later in the article, we worked with an accessibility specialistwho uses a screen-reader. We chose to design the map in a spreadsheet. Thismade it easy for our colleague to offer feedback. Figure 3: Exampleof accessibility use case map. Solutions are indicated on the x-axis. All ninedisabilities are listed on the y-axis. Each solution is assessed for degree ofimpact: impactful, helpful, it depends, not relevant, and inaccessible. Thiscriteria is discussed later in this article.  We wanted our map to help prioritize solutions that maximized benefits forVeterans living with a variety of disabilities, while minimizing the chancesof introducing barriers.Here's how we created the accessibility use case map.Step 1: Developed proto-personas for each type of disabilityWe chose nine of the most common types of disabilities reported by Veterans:  Blindness  Low vision  Hard of hearing/deafness  Cognitive disability  PTSD  Motor disabilities  Military Sexual Trauma (MST)  DeafblindnessTime and resources were limited. So we used secondary sources and "bestestimates" to develop light-weight personas of each disability type ( proto-personas).Each described the behavior, symptoms, needs, and tools used to manage thecondition. This allows for quicker, iterative research. Figure 4: Exampleof a proto-persona for a Veteran living with low-vision. We used secondaryresearch sources to validate our assumptions on behaviors, needs andchallenges. Details of the post-it notes are intentionally not-visible, andare shown for example purposes only.Step 2: Created user journey maps to identify pain points and possible solutionsBased on the proto-personas, we created user journey maps across the medicalappointment experience:  Before checking into an appointment  During the appointment, and;  After the appointmentWe proposed solutions to help address pain points across the journey for eachtype of disability. Figure 5: Exampleof user journey map for a Veteran living with low vision and may needcaregiver support to prepare for the medical appointment. Details of the post-it notes are intentionally not-visible, and are shown for example purposesonly.Step 3: Mapped each solution across multiple disability types, creating our accessibility use case mapBut what might benefit someone with one type of disability, might be a barrierfor others. For instance, text-to-speech software is helpful for a blindVeteran trying to access their appointments. But it may be inaccessible to aVeteran who is hard of hearing.Due to this challenge, we decided to map each proposed solution across the 9most common disabilities affecting Veterans.We listed recommendations along the x-axis. We then listed the ninedisabilities along the y-axis.For each type of disability, we assessed if the solution was:  Impactful (positive and we believe will enhance the experience for this disability)  Helpful (positive and it's not specific to this disability)  It Depends (it may depend on the degree or type of disability, or the recommendation is too complex for us to weigh in at this point)  Not Relevant  Inaccessible (it's a barrier for a person with this disability)Step 4: Iterated with various accessibility expertsTime constraints didn't allow us to validate with users (which would've beenideal). Instead, we iterated on our map with various accessibilityspecialists:  Josh Kim (Accessibility Designer)  Martha Wilkes ( Accessibility Strategist at the VA Office of the Chief Technology Office)  Melissa Manak (Senior User Experience Mobile Designer)  Angela Fowler (Senior A11Y Specialist and Designer)  Vanessa Luxen (an IAAP certified professional and former Audiologist at CivicActions)Some of the experts we consulted also lived with a disability. This helpedensure we were including the lived experiences of the very people we weredesigning for.Step 5: Developed an "Accessibility Impact Score" for each recommendation.Working with our accessibility experts, we assigned a value depending on howhelpful or unhelpful the solution was for each type of disability. We calledthis our "Accessibility Impact Score."  3 for Impactful (positive and we believe will enhance the experience for this disability)  2 for Helpful (positive and it is not specific to this disability)  1 for It Depends (it may depend on the degree of type of disability, or the recommendation is too complex for us to weigh in at this point)  0 for Not Relevant  -2 for Inaccessible (it is a barrier for a person with this disability)We then tallied the number of scores for each solution to calculate the final"Accessibility Impact Score."This helped us assign a numerical value to evaluate the impact eachrecommendation would have across multiple disabilities. For instance,improvements like "sending an SMS notification with a link to pre-check-in"was one of our highest impact solutions. This meant it was impactful for thegreatest number of disabilities.Step 6: Prioritized recommendations based on the Accessibility Impact ScoreUsing a prioritization matrix, we prioritized each recommendation based on itstotal Accessibility Impact Score.We refined it further with our product team based on scope and feasibility, sowe could eventually choose the recommendations we wanted on our roadmap.We took some risks and made many assumptionsThere are many caveats with our framework, for instance:  It favors specific solutions that are impactful for a few disabilities and may end up with a lower score vs. general solutions that help a variety of disabilities.  We did not capture the complexity within each disability type. For example, cognitive disabilities can include a range of disabilities that vary in severity, symptoms and more. We recognize disabilities are not a monolith and the experiences are complex and varied.  It doesn't take user preferences or familiarity with the technology into account  It's not intersectional — it doesn't consider people who live with more than one disability  We didn't test it with users living with disabilities.  This is our first attempt at designing for disabled Veterans when resourcesare limited, time-frames are tight, and priorities conflict.Ideally, disabled Veterans would be part of our processWhat would we have done differently without those constraints? We would haveincluded disabled Veterans throughout all six steps of the process. This waywe'd design with (not for ) the disabled Veteran community.What's next?This framework is dynamic. We plan to continue to iterate as we address ourmany assumptions. We hope to start conducting user research sessions withVeterans living with disabilities to validate (and invalidate) our proposedimprovements.Authors: Nira Datta, Senior Content Designer at CivicActions; Ya-ching Tsao,Product Designer at CivicActionsHelping disabled Veterans Check-In: Designing an AccessibilityMap was originally published inCivicActions on Medium, where people arecontinuing the conversation by highlighting and responding to this story.",
      "date"     : "2023-04-06 16:00:00 +0000"
    },
  
    {
      "title"    : "Opensource.com: How I do automated accessibility testing for my website",
      "url"      : "/posts/opensource-automated-accessibility-testing",
      "content"  : "Opensource.com published a guest editorial we wrote automated accessibility testing and how it is done on GitLab using Pa11y CI and Cypress.Full post: How I do automated accessibility testing for my website",
      "date"     : "2023-03-02 16:00:00 +0000"
    },
  
    {
      "title"    : "Mike Gifford gave a presentation at FOSDEM on Accessibility & Open Source",
      "url"      : "/posts/FOSDEM-ccessibility-OpenSource",
      "content"  : "I presented on February 5th in the Design track of the conference. The slides and presentation are available to those who missed it.My presentation focused on my experience in Drupal. Drupal has been a leader in digital accessibility for over an decade. Working with an open community has allowed us to pioneer some new solutions to common design challenges. Working in the open has allowed us to tap expertise outside of our community and given space for people with disabilities to become involved in a variety of roles. Accessibility best practices make it clear that accessibility needs to be considered at all levels of a project.This talk draws on the experience of the Drupal community but isn't limited to it. I touched on the We4Authors Cluster initiative of Funka with the European Commission.",
      "date"     : "2023-02-05 16:00:00 +0000"
    },
  
    {
      "title"    : "Mike Gifford Presented in at Inclusive Design & Accessibility Meetup in the Netherlands",
      "url"      : "/posts/governments-accessibility-opensource",
      "content"  : "I presented Governments, accessibility and open source in Utrecht. My slides are available, and we hope to make the audio available soon.My talk focused on some of the challenges that governments are facing as they work to modernize and adopt modern digital first practices. In my talk I address Open Government, open source software and Civic Tech. I highlight how digital accessibility is a huge challenge for governments. Often innovation clashes with inclusive design. There is new legislative pressure on governments, and governments are always struggling to do more with less.",
      "date"     : "2023-02-01 16:00:00 +0000"
    },
  
    {
      "title"    : "Daniel Mundra interviewed on the Talking Drupal podcast",
      "url"      : "/posts/Talking-Drupal-Podcast-382",
      "content"  : "I joined Ben Mullins on the Talking Drupal podcast #382 to discuss Automated A11y Testing with Nightwatch. We discussed the efforts of adding the accessibility tests to Drupal core, accessibility in general, Cypress vs Nightwatch, and so on.",
      "date"     : "2023-01-16 16:00:00 +0000"
    },
  
    {
      "title"    : "Mike Gifford & Daniel Mundra interviewed on the Talking Drupal podcast",
      "url"      : "/posts/Talking-Drupal-Podcast",
      "content"  : "Mike and I were interviewed on the Talking Drupal podcast #350 on Accessibility Scanning & Testing. We discussed various tools, strategies, OpenACR, and so on.",
      "date"     : "2022-05-31 16:00:00 +0000"
    },
  
    {
      "title"    : "CivicActions Accessibility Pledge",
      "url"      : "/posts/CivicActions-Accessibility-Pledge",
      "content"  : "The World Health Organization estimates the number of people with disabilities in the world is more than 1 billion—and everyone experiences temporary or situational disabilities.  According to the WebAIM 2022 report on the accessibility of the top million sites, 96.8% of home pages have accessibility failures.CivicActions recognizes that the digital world is the operational hub for critical human services. By safeguarding and committing to an accessible digital future, we ensure more people can get the help they need, and service-providers can readily engage.To continue to advance our accessibility maturity,  CivicActions has established the following:  Introduction to Accessibility as part of employee onboarding  CivicActions Global Accessibility Community of Practice  Free and Open Source Software Products, such as site-wide accessibility monitoring tools and the OpenACR project.  Inclusive agile development process  Accessibility Champions Program  Annual engagement in events like Global Accessibility Awareness Day (GAAD)Today, we reaffirm our commitment to digital accessibility with this pledge.CivicActions hereby pledges to build and maintain digital tools with the following guidelines.  Our work will be continuously monitored          Integrate best of breed accessibility testing into our continuous integration processes      Ensure all developers and designers start using accessibility tools in their editors      Automated site-wide testing and historical analysis will be used      Site-wide test scores and improvement targets will be incorporated into agile process      Manual testing will be done alongside automated testing to catch issues that automated testing cannot evaluate      Testing with users with disabilities where possible to see that people with lived experience evaluate critical tasks      Incorporate structured WCAG-EM evaluations into contractual annual reviews with our clients        Upon onboarding, we will inform our teams, partners, and clients about why accessibility is important and set collective priorities          We will define and document success for accessibility in Human Centered Design, Customer Experiences and Section 508 compliance, among other priorities      These agreed-to accessibility priorities will be incorporated into our Project Charters and regularly reviewed by our team      We will have designated accessibility champions on all projects and work to have IAAP Certified and/or DHS 508 Certified staff        As a company, CivicActions will set annual goals and report against them publicly on CivicActions.com/accessibility-reports (Future Location)          Strive for no accessibility errors as much as can be identified through our automated testing process      Document process for choosing representative sample of pages for reviews      Detail what testing processes have been set up for each projects and what common code has been shared      Authorized by Henry Poole, CEOMay 19, 2022",
      "date"     : "2022-05-19 00:00:00 +0000"
    },
  
    {
      "title"    : "How Drupal helps us bake accessibility into every project",
      "url"      : "/posts/how-drupal-helps-us-bake-accessibility-into-every-project",
      "content"  : "Learn key features of Drupal that help make your site useful to people of all abilitiesPhoto by CliffBoothfrom PexelsAs developers and designers working to help government agencies modernizetheir IT systems and websites, we are constantly aware of the far-reachingimpact of our work. Many people stand to benefit from better governmentexperiences online — that is, if we do our job well. If not, people maystruggle to navigate websites that don't properly address accessibilityissues.We believe that accessibility is not just for meeting requirements — it's forthe people (of varying abilities and circumstances) who are relying ongovernment websites for critical information and services. So we built acommunity of practice to share andlearn with others who are doing this work, and we choose open source toolsthat support accessibility in the long term.Drupal is one of those tools — a content management platform that iscontinually updated to help people meet evolving accessibility standards. AtDrupalCon North America 2021,CivicActions engineer Jennifer Aube gave a lightning talk to explain some ofthe features of Drupal that come built-in to support accessibility. Have alook!https://medium.com/media/1930322fa36c62488ab5a0487169f1d4/href  "Every person deserves an equal opportunity to engage in all sites." —Jennifer AubeHighlights  0:30 — Why should we care about accessibility?  1:27 — Disability simulator: See a live demo of how people experience disability  3:23 — Why you shouldn't turn off alternative text functionality  4:15 — How "skip navigation" helps disabled people get right to the important content  5:00 — What are "field sets" and how are they used?  5:47 — Tips for using form labels effectively  6:32 — Help users get around the site without a keyboard  8:07 — How to use Google Disability Simulator  9:00 — Q&AResources  Deck: 5 Ways Drupal helps us bake accessibility into every project  Web Disability Simulator from Google  Accessibility Community of Practice powered by CivicActionsConnect with Jennifer  LinkedIn  GitHub  DrupalHow Drupal helps us bake accessibility into everyproject was originally published inCivicActions on Medium, where people arecontinuing the conversation by highlighting and responding to this story.",
      "date"     : "2021-12-13 16:00:00 +0000"
    },
  
    {
      "title"    : "CivicActions creates Open Product Accessibility Template (OPAT) with the GSA",
      "url"      : "/posts/CivicActions-Creates-Open-Product-Accessibility-Template",
      "content"  : "CivicActions is working with the GSA to modernize the VPAT process to ensure that it is machine-readable. The goal of this process is to help make accessibility conformance monitoring easier and more meaningful for everyone. You can more about this project on the OPAT GitHub Project and we are actively encouraging people to submit suggestions on how it could be improved.This project has several goals. We are working to build an Accessibility Conformance Report(ACR) that is:  Transparent - Easily comparable compliance reports.  Validatable - Confidence that reports meet minimum standards.  Aggregable - Enterprise-wide accessibility confidence.  Versioned - ACRs should follow digital best practices.Modern ACRs need to be:  machine-readable  able to integrate with modern software development tools  aligned with modern software versioning  easily editable and comparable  centrally updated and publicly availableOur work with the GSA is helping set the foundation for this work.",
      "date"     : "2021-08-13 00:00:00 +0000"
    },
  
    {
      "title"    : "CivicActions wins contract to produce a machine-readable Voluntary Product Accessibility Template® (VPAT®)",
      "url"      : "/posts/gsa-machine-readable-acr",
      "content"  : "We're thrilled to be helping the GSA improve its digital accessibility by improving procurement! The standard Accessibility Compliance Report(ACR) for the last two decades has been the Voluntary Product Accessibility Template® (VPAT®). Moving to a machine-readable format will make it easier for everyone to have better knowledge of software accessibility.As announced on g2xchange this process will move ACR from an essentially paper-based format to one that is in well structured digital files that can be validated. Having a standardized machine-readable format will make it easier for people to compare between versions of a given digital tool, as well as between multiple tools.",
      "date"     : "2021-08-11 14:00:00 +0000"
    },
  
    {
      "title"    : "What we learned about accessibility by scanning more than 2 million federal .gov web pages",
      "url"      : "/posts/scanning-over-two-million-gov-pages",
      "content"  : "On July 22 Mike Gifford and Luke Fretwell had this article published in FCW (Federal Computer Week) to highlight months of work scanning federal .gov web pages.We tested against 2.1 AA requirements, the current best practice for digital accessibility standards. The open source tools we used were Domain Accessibility Audit (to crawl the pages) and axe (to perform the actual accessibility scans).These problems are happening because accessibility has been an afterthought, even in government. In order for accessibility success to scale in the enterprise we need to take a more holistic approach. For this we have developed our HEART framework.Learn more by reading our NEXTGOV/FCW article.",
      "date"     : "2021-07-30 14:00:00 +0000"
    },
  
    {
      "title"    : "HEART: Ensuring government digital services accessibility",
      "url"      : "/posts/heart-accessibility",
      "content"  : "To help government agencies holistically address digital accessibility, we've developed a phased organizational framework we call HEART.Holistic Enterprise Accessibility Review Technique is a proactive, interactive process to ensure government digital services are accessible to everyone.HEART provides guidance for all stakeholders and aims to address every aspect of organizational operations, including policy, procurement, technical, resourcing and culture.Learn more about HEART and contact us if you need accessibility support in your organization.",
      "date"     : "2021-06-01 14:00:00 +0000"
    },
  
    {
      "title"    : "Plain language page added to CivicActions Accessibility Guide",
      "url"      : "/posts/plain-language-accessibility-guide",
      "content"  : "We've added a plain language page to the CivicActions Accessibility Guide.You can find:  quick tips on how to keep simplify your content  helpful automated tools that check for plain language  plain language communities you can join to learn more.If you have feedback or would like to improve this page, we encourage you to submit an issue or pull request.",
      "date"     : "2021-05-28 14:00:00 +0000"
    },
  
    {
      "title"    : "Social media page added to CivicActions Accessibility Guide",
      "url"      : "/posts/social-media-accessibility-guide",
      "content"  : "We've added a social media page to the CivicActions Accessibility Guide.This includes tips for:  Text  Hashtags  Images  Video  Emoji  and related resourcesIf you have feedback or would like to improve this page, we encourage you to submit an issue or pull request.",
      "date"     : "2021-05-27 14:00:00 +0000"
    },
  
    {
      "title"    : "How we scale inclusive website content with automated testing and open source tools",
      "url"      : "/posts/how-we-scale-inclusive-website-content-with-automated-testing-and-open-source-tools",
      "content"  : "Since launching the CivicActions Accessibility website, we've had 9 contributors on GitHub and many more contributing to our guide, playbooks, and posts.We value openness, agility, inclusiveness and continuous improvement. Ensuring that our site is consistently built makes it easier to maintain in the long-run.As our website grows, we want to ensure our content mirrors our values — and that it scales with ease. So, we have enabled automated testing (and some updating) of text when it's submitted in a pull request.Content goals that match our valuesIt is important that this site demonstrates our values by being accessible and professional. That's why we eliminate unclear, insensitive language that could alienate our audience.Automation is not full-proof. It doesn't have context to understand why a sentence is structured a certain way or why particular words are used. It is a tool in our arsenal to help us continuously improve, like catching terms that might be offensive or simplifying complex sentences, and so on.The technologyMost content changes are done through plain text editors or directly on GitHub. So, many of the conveniences that are built into modern word processing applications aren't available. The following tools help us keep the quality of our site high.To achieve the testing we use the following technologies:  remark: A markdown processor (Markdown is how we write all our content that is then compiled into static HTML pages by Jekyll).  retext: A natural language processor to check for issues in the text.  reviewdog: Takes the errors and warnings from remark and retext and comments on the markdown text in the code (pull request) indicating the issues and recommended corrections.  pre-commit: Also test files for any issues and in some cases updates the text automatically.  docker and GitHub Actions: Used to run the reviewdog scripts with remark and retext whenever a pull request is submitted.The setupFor remark/retext we create a Docker image that installs the dependencies and sets up reviewdog to execute our configuration on a pull request. The details are visible in our repository but here are the important bits.The following files (truncated for brevity) configure the plugins for testing markdown and text — and their individual settings.Here are some of our example settings:  Markdown bullets denoted with an asterisk '*'.  Single space between sentences.  Straight quotes (note this down, it will be important later in the post).  Readability set to 18 years.  Checking for spelling mistakes.  Checking for insensitive or inconsiderate language.remarkrc.problem file:{  "settings": {    "listItemIndent": "1",    "bullet": "*",    "strong": "*",    "emphasis": "_",    "fences": true  },  "plugins": [      "remark-frontmatter",      "remark-validate-links",      "remark-comment-config",...      ["remark-lint-table-cell-padding", "consistent"],      ["remark-lint-table-cell-padding", "consistent"],      ["remark-lint-unordered-list-marker-style", "*"],      "./retext.problem"    ]}retext.problem.js file:"use strict";...module.exports = attacher;function attacher() {  this.use(    remark2retext,    unified()      .use(english)      .use(sentenceSpacing, { preferred: 1 })      .use(quotes, { preferred: "straight" })      .use(repeated)      .use(indefinite)  );}retext.suggestion.js file:"use strict";...function attacher() {  this.use(    remark2retext,    unified()      .use(english)      .use(contractions, { straight: true })      .use(readability, {        age: 18,        minWords: 15,        severity: "fatal",        threshold: 5 / 7,      })      .use(equality, { ignore: ignoreWords || [] })      .use(spell, dictionary)  );}The executionSimilar to our automated accessibility testing post, we use GitHub actions to run our set up on pull requests. The setup is also tuned to only check the changes for the text issues and not all files. This encourages authors to focus on the changes they are submitting.ExamplesIn pull request 373 and the below screenshot you can see that the sentence, "Whole websites can now be easily crawled for bugs" that the word 'easily' has been flagged as may be insensitive and we should try to avoid it.In pull request 374 and the below screenshots you can see that I took an earlier version of this post and ran it through the process and got some good feedback.In this screenshot we see a warning about a hard to read sentence.In this screenshot we see that a typo was misattributed as an insensitive word.Automating changesSome of the recommendations that are provided could be automatically edited, like changing smart quotes to straight quotes (remember the note from earlier). We do this using the pre-commit tool and here is an example:In this screenshot we see a warning about a smart quote:In this screenshot the change is made for us and committed to the pull request:You can see the details at this URL: pull request 342.Future considerationsWe are interested in adding the retext-simplify plugin to check phrases for simpler alternatives and maybe reduce the age for readability. Check out the available plugins in the retext documentation.ConclusionFollowing this set-up can help you inject tools to help you test your content. But remember, automation can be devoid of context and can still contain our biases.You should keep tweaking the tools and double-check your content to make sure it meets your values.Further reading and examples  The same tools above are used in:          Quality docs.      CivicActions handbook.        Some similar tools for GitHub and other applications:          A markdown proofing platform for individuals, teams, and organizations.      Readability Check.      status-stats-jbrains package.      Thank you to Michelle Kang, Marlena Medford, Luke Fretwell, and Mike Gifford for your support, thoughts, and feedback.",
      "date"     : "2021-05-25 14:00:00 +0000"
    },
  
    {
      "title"    : "Open analytics on the CivicActions Accessibility website",
      "url"      : "/posts/website-analytics",
      "content"  : "We are now openly sharing analytics information for the CivicActions Accessibility website.We believe in open analytics and data and, by publicly sharing our website analytics publicly, we hope that others might learn from our work. We also believe it is an opportunity for anyone to use this information to help usTools we're using to gather and display this information:  Google Analytics  Google Data StudioCivicActions Accessibility website analytics",
      "date"     : "2021-05-24 16:00:00 +0000"
    },
  
    {
      "title"    : "Pre-GAAD event: Authoring tools with built-in accessibility",
      "url"      : "/posts/pre-GAAD-Authoring-Tools-Built-in-Accessibility",
      "content"  : "Today is the Global Accessibility Awareness Day or GAAD, and people around the world organize events to raise awareness about digital accessibility. Especially as everything is online these days, GAAD has become something that celebrate throughout the month of May.2020 was the 10th anniversary, and also the launch of the GAAD Foundation.I represented Drupal in Funka's We4Authors Accessibility Cluster. Yesterday, Funka organized a pre-GAAD event to highlight the importance of authoring tools.The We4Authors Cluster is a multi-CMS (Content Management System) group that is working to better support authors. Authors need to be subject matter experts, not accessibility experts, and CMS tools can help make their job easier. It should be simple for everyone to produce accessible content. For folks familiar with the W3C's Web Accessibility Initiative, it is essentiallylooking at implementing Authoring Tool Accessibility Guidelines (ATAG) 2.0 - Part B. By bringing together leaders in CMS solutions that are popular with governments in the European Union, we are finding solutions which can help many of the authors that will need to implement the European Union's Web Accessibility Directive.The challenge that governments face to see that their digital solutions are able to meet the needs of all citizens is significant. By working together and funding common solutions to widely used libraries the European Commission is able to make a very cost-effective contribution to improving accessibility. Millions of citizens in member states will benefit from having better accessibility defaults.Both proprietary & open source communities were involved in the We4Authors Cluster and both can help develop common best practices.It was also terrific to see the efforts that the organizers placed on accessibility for this event. A live captionist was engaged for the event. That text was automatically translated into multiple languages so that representatives in non-English speaking countries could participate.Building in accessibility best practices can really help so many people engage with digital content. Everyone can benefit, whether they have a disability or not.",
      "date"     : "2021-05-20 22:00:00 +0000"
    },
  
    {
      "title"    : "Launching a community of practice for accessibility in government services",
      "url"      : "/posts/launching-a-community-of-practice-for-accessibility-in-government-services",
      "content"  : "On Global Accessibility Awareness Day, we're excited to be announcing the launch of our initiative to advance accessibility awareness and best practices in government digital services.Photo by PorapakApichodilokfrom PexelsPeople tend to think of disability as a characteristic of a person. But often,the mismatch between design and the person is what causes the disability. Intoday's tech-driven world, designing and building for people with differentabilities enables more of society to access essential services. It makes for amore inclusive world.Creating accessible websites is a growingpriority within the government.But accessibility goes beyond compliancerequirements. It's something we canconsider at every step of a service, holistically across government, tobenefit the greatest possible number of people.That's why we launched the CivicActions Accessibility Practice Area, toestablish a community of learning and growth around accessibility bestpractices. It's something we all need to work on, from the vendors buildingdigital services to the agencies delivering them to the public. And this workis never "done" — we know there is always more to do, and we invite everyoneto do it with us.Building a foundation for accessibility best practicesWe're working on embedding accessibility into our offerings by:  Developing a proactive, interactive process to make government services accessible to everyone, called the Holistic Enterprise Accessibility Review Technique (HEART)  Incorporating accessibility into our human-centered design process at CivicActions, ensuring that our design practices integrate accessibility into our client work  Building accessibility personas to drive our design thinking, and building our 'designer's accessibility toolkit' with templates to guide each phase of the decision making process  Exploring how we might incorporate plain language service training  Creating recommendations on how to structure project teams to include accessibility from the start  Integrating accessibility into our processes and workflows, including company materials like our handbook, contracts, and proposalsPhoto by JuditaTamošiūnaitėfrom PexelsWe're passionate about fixing problems "at the source", which has led us tofocus on improving legacy procurement — right where many accessibilityproblems begin. We're currently developing an open, machine-readable templateto help organizations show how well their product meets accessibilitystandards. It's our version of the current standard, known as VoluntaryProduct Accessibility Template (VPAT). We hopeit will provide a better alternative for agencies looking to accurately gaugethe accessibility of the products they are considering.Creating a community hub for accessibilityTo help build enthusiasm and education around accessibility, we developed anopen source website with resourcesand best practices. It serves as a digital hub for our growing community.We're already seeing a growing interest in the conversation on improving theaccessibility of government services. We've presented at the General ServicesAdministration (GSA) Accessibility Guild and the GSA has incorporated ourautomated testing solution on their website.We're also talking about:  Why we need accessibility compliance as code  How to integrate accessibility early and throughout your process  Why anchor links are a must for government agencies  How to run automated testing on your GitHub-hosted Jekyll site  Why open-source collaboration is key to busting silosWe're using and building on a range of government accessibility sourcesincluding the United States Web Design System (USWDS), 18F, and the UK'sGovernment Digital Services. We're beginning to influence the conversation too(our automated testing solution is now part of 18F'splaybook). This justshows how we can all work together to build a stronger global community ofdigital services professionals who all want to make a more accessible world.Building capacity in our own organizationIt can be difficult informing busy professionals about accessibility. To adoptnew ways of thinking and working as an organization, you have to embedaccessibility as part of the culture. So our community of practice also servesas an internal accessibility support team. We want to make it easier for ourcolleagues to grow their knowledge and expertise. To drive internal education,we:  Maintain an accessibility playbook and guide with a focus on open source solutions serving government  Promote and educate about solutions that are relevant, scalable, and reliable  Treat accessibility questions within the organization like a customer support ticket, making it easy for our colleagues to ask questions and get help  Run an accessibility study group within the organization to develop professional skills in accessibility (and work towards certification)  Host a Slack channel to discuss current events and articles on accessibilityThecommunity of practice helps us build a culture of accessibility in our ownorganization and beyond.Collectively, this helps us build accessibility confidence within theorganization, so CivicActioners can more readily apply it to projects.Measuring successThere are plenty of metrics to measure how we're advancing our mission. As weramp up, we are strategically choosing to measure our success through:  Impact through our new accessibility site, which is emerging as a useful resource and establishing credibility  Growth of accessibility as a service that we provide to the government, as evidenced by the number of submissions on our contact form and traffic to the accessibility service pages (which we'll be publishing soon!)  Expansion of our practice area, specifically by the number of members and engagements in weekly meetings  Increase of feedback on our accessibility statement, which helps us understand how we can better meet the needs of our visitors.Some folks in theCivicActions Accessibility community of practice.How we workNobody has all the answers. That's why we work in the open. We believe this isthe best way to improve our practices. We work in an agile environment and useGitHub to drive innovationthrough open development.Collaborate with usWant to work with us? Have ideas on how we can improve? Please reachout.Learn more  Challenges in automating accessibility  Writing impactful accessibility reports  Accessibility initiatives from the White House  How open source tools improve accessibility for government  Tools to help government web authors make accessible contentLaunching a community of practice for accessibility in governmentservices was originallypublished in CivicActions on Medium, wherepeople are continuing the conversation by highlighting and responding to thisstory.",
      "date"     : "2021-05-20 16:00:00 +0000"
    },
  
    {
      "title"    : "Q&A with Mike Gifford: Accessibility in civic tech",
      "url"      : "/posts/qa-with-mike-gifford-accessibility-in-civic-tech",
      "content"  : "Mike Gifford is a SeniorStrategist at CivicActions, a Drupalcore maintainer, and accessibility advocate. He's passionate about changingthe conversation around accessibility in civic tech by moving beyondcompliance to view these needs for what they are: a humanright.Senior Strategist Mike Gifford in his natural habitatThe world of civic tech is deep and wide. Why accessibility? What approachshould we be taking as we attempt to learn about issues within theaccessibility community?Photo of Alan and Mike, courtesy of Mike'sFlickrMike: For me, it started with ** empathy and friendship. Alan Shain,who's been a roommate and friend since 1990, has cerebral palsy. He's a formerbureaucrat and a comic who has been active in the Canadian arts community.He's taught me the importance of the disability rights movement. Knowing himgot me thinking more about humanity and the abilities we possess, and thenotion that we are all only "temporarily able-bodied." We have some abilitiesright now, but that may change drastically tomorrow. As we grow older, thingsinevitably happen to our bodies. Yet, we have a big aversion to the idea ofour own mortality, so we often overlook that.  "We are all only temporarily able-bodied — we have some abilities rightnow, but that may change drastically tomorrow."Through many conversations with Alan, I've become more appreciative of howother people move through this world. There's much more to accessibility thanpeople realize. It helps to open our minds and consider that there aretemporary and situational disabilities, such as ones caused by medications, oreven by losing your glasses. You could have trouble doing your taxes becauseyou have to care for your children, or because you're simply struggling tojuggle more than one thing at a time. You could be trying to access a websitewith low contrast while outside on a sunny day. These are all examples ofaccessibility issues.  "There are temporary disabilities and situational ones, such as onescaused by medications, or even by losing your glasses."PerfectoCapucineon UnsplashWhen you think about web accessibility, what are some common misconceptionsor mistakes you see? How can they be addressed?A lot of people assume things are accessible, when in fact they are not. TakeDrupal's website, for example. People assume that Drupal.org is accessible,and therefore, no other work needs to be done. While Drupal has some built-inaccessibility features, there are other issues that aren't coming to light.I would love to have people adopt the mindset that accessibility featuresshould be included from the start, and not as an afterthought. Wanting to bemore accessible today than yesterday should always be the goal. This meansbuilding frameworks that pave the way for inclusive, forward-thinkingpractices. We're dealing with something that changes all the time, so it'sabout more than just performance. We need to be constantly finding ways ofbringing more people into the conversation; we're excluding far too manypeople.  "I would love to have people adopt the mindset that accessibility featuresshould be included from the start, and not as an afterthought."What changes have you seen over time in this industry?The number of educational resources addressing accessibility issues hasincreased significantly. And they are much more timely and interesting than adecade ago, when the conversation first shifted towards these issues.For example, tools like axe accessibilitytesting provide more opportunities to uncoverproblematic issues on websites. It would be great if we could monitor thoseinstances even more. In Europe the government is tasked with monitoring theaccess of all public websites. The results have to be published, which holdsthem accountable to the standards they set, and increases the transparency ofexisting issues. If a department scores low on accessibility compliance,people will know, and expect a response. It's like checkers! The good thing isthat there are standard automated tools that can trawl websites and show whereimprovements can be made.AndyFeliciottion UnsplashWhere do you see web accessibility going in the future? Do you have any"big bets" when it comes to emerging technologies or trends?I think ** VR and augmented reality will have a big impact soon. We're atthe edge of them being more meaningfully included in our lives. It would begreat for engagement — an interactive way to start thinking about how to makeemerging technologies more accessible. Computers are built into so manydevices, but they still contain significant impairments. Washing machines andother appliances could be adapted to be more intuitive, too.For people reading this, how can they be part of the solution?Ask questions and explore what's out there. Educate yourself, and spend timetrying to understand how other people interact with the web and how importantthat access is to all of us. Look into features like the Wave toolbar andaccessibility insights from Microsoft to get a sense of accessibility issuesthat others face. These tools are great for evaluating and aiding in awarenessof the existing problems, and are structured to give users a visual cue ofwhere they might be.Also, try to make the conversation about accessibility personal. Ask peopleabout the needs their parents might have as they age. What general challengeswill they face? For example, when you're younger, it's easier for you tomemorize things. but that changes as we age. Show people how we face similarchallenges at different points in our lives, and normalize addressing thoseconcerns now rather than later. That said, there are one in five peoplesuffering from permanent disabilities, so the probability of you knowingsomeone with one is very high.  "Try to make the conversation about accessibility personal."Why should the government prioritize web accessibility in procurement?Government is the largest single purchaser of goods and services, so as anentity, it has a huge impact on setting accessibility standards for everyoneelse. If the government commits to only buying accessible tech, it will changethe world. Currently though, the federal government often favors certaincorporations, or software or tools that have barriers to accessibility.  "If the government commits to only buying accessible tech, it will changethe world."ThisisEngineeringRAEngon UnsplashDo you see open source software as a way to improve accessibility atscale?Yes, using open source tools can actually be part of an accessibilitystrategy for a government organization.For example, Drupal issues can affect a million websites that use it, butbecause it is open source, fixing issues in the Drupal core fixes themeverywhere — the scalability is huge. With proprietary software, you'll haveto cobble together your best hope of an answer to any issues that arise. Youmay not be able to share information outside of a silo because of bureaucraticor intellectual property issues with the software you are being forced to use.  "Open source tools can actually be part of an accessibility strategy for agovernment organization."It's more efficient to work in open source because when we get it right, itscales. The cost to the taxpayer for methods using proprietary software isunsustainable; there's no way to share the wisdom. Everyone is struggling tofind the same solutions to problems, and they end up cobbling somethingtogether instead of working effectively. Open source tech allows you toexplore all your options and get the best answer to a problem, because youhave a whole community supporting it. If you have questions about something,and the community answers them for you, it's being answered for everyone else,too.Learn more  Mike Gifford at DrupalCon Global 2020  Challenges in automating accessibility  Writing impactful accessibility reports  Accessibility initiatives from the White House  How open source tools improve accessibility for governmentConnect with Mike  LinkedIn  GitHub  Medium  TwitterQ&A with Mike Gifford: Accessibility in civictech was originally published inCivicActions on Medium, where people arecontinuing the conversation by highlighting and responding to this story.",
      "date"     : "2021-05-06 16:00:00 +0000"
    },
  
    {
      "title"    : "Smashing Magazine: 'How To Bake Layers Of Accessibility Testing Into Your Process'",
      "url"      : "/posts/smashingmag-baking-in-accessibility-testing",
      "content"  : "I co-authored an article with Kate Kalcevich who is the Head of Services at Fable about accessibility testing.How To Bake Layers Of Accessibility Testing Into Your Process introduces "layered accessibility testing" to readers. This is a practice of using a variety of tools and approaches at different stages in the digital product lifecycle to catch accessibility issues early — when it's easier and cheaper to fix them.Using the metaphor of a layered cake, Mike and Kate highlight how teams can gather the ingredients that they need to build accessible products and services.",
      "date"     : "2021-04-27 22:00:00 +0000"
    },
  
    {
      "title"    : "CivicActions Accessibility Guide now available",
      "url"      : "/posts/mvp-guide",
      "content"  : "The first iteration of the CivicActions Accessibility Guide is now available for public use. This is an evolving effort, and we will continue to update it based on community feedback and internal efforts to improve its usefulness.To contribute to the guide:  Submit an issue at our GitHub queue  Submit a pull request  Start a discussion",
      "date"     : "2021-04-15 16:00:00 +0000"
    },
  
    {
      "title"    : "CivicActions Accessibility Playbook now available",
      "url"      : "/posts/mvp-playbook",
      "content"  : "The first iteration of the CivicActions Accessibility Playbook is now available for public use. This is an evolving effort, and we will continue to update it based on community feedback and internal efforts to improve its usefulness.To contribute to the playbook:  Submit an issue at our GitHub queue  Submit a pull request  Start a discussion",
      "date"     : "2021-04-14 16:00:00 +0000"
    },
  
    {
      "title"    : "Mike Gifford interviewed on the AT Banter Podcast",
      "url"      : "/posts/at-banter-podcast",
      "content"  : "I was interviewed on the AT Banter Pocast - Episode 230 on a wide-ranging interview that covered technology, legislation and everything in between.From the interview:  Well, I think that the standards are changing, and the technology is changing. There's, there's a lot of good in that. But it also means that, that you really have to transition how you think about accessibility from being a checklist where you'd say, "yes, it's accessible", to be more of something where you see it as a journey.Full transcripts: Episode 230 with Mike Gifford",
      "date"     : "2021-03-30 16:00:00 +0000"
    },
  
    {
      "title"    : "Government Accessibility and the CMS Problem",
      "url"      : "/posts/government-accessibility-and-the-cms-problem",
      "content"  : "How an open source pilot project is empowering content authors to build a more inclusive world Photo bySigmundon UnsplashAt DrupalCon Europe 2020, CivicActionsSenior Strategist Mike Gifford discussed the common barriers to accessibilitywhen authoring content for the web. Both he and co-presenter Susanna Laurin,Chief Research and Innovation Officer atFunka, shared the initiatives thatthey, along with other industry experts, have started to address with theWe4Authors Cluster — a pilot funded bythe European Commission to create and implement default accessibility featuresinto authoring tools popular in with member states of the European Union.The main problem facing web authors is that most Content Management Systems(CMS) expect them to be knowledgeable about accessibility, when the reality isthat many of them, including government agents, lack the formal training andtechnical knowledge to create accessible content.As a Drupal core accessibilitymaintainer, Mike shared the efforts thathave been made within the Drupal community to meet ATAG 2.0standards, and talkedabout the areas in which they could be improved. Rebuilding CMS interfaces tobe both intuitive and reactive, and then making them publicly available, isthe next logical step in helping authors to make accessible content morewidespread.https://medium.com/media/e111fcdd66bd158ee3f371c19d97c15f/href  "There are going to be huge benefits for the Drupal community. Being a partof [We4Authors] allows us to share problems, ideas, wireframes and even codewith other teams … This is a great way for us to learn from each other andtest ideas with government authors." — Mike GiffordHighlights  6:09 — Enhancements to Drupal core, and how they help web authors make more accessible content  7:05 — CTA: Help authors discover accessibility tools they didn't know about  9:31 — EU regulations on accessibility standards  12:12 — Why 50% of accessibility problems are created by web authors, and what we can do about it  13:14 — Reasons to build accessibility tools into the CMS  13:44 — If we could go to the moon, there's no reason why we can't make accessible authoring tools  14:59 — If the most popular CMS platforms commit to compliance, others may follow  15:45 — Drupal is the #1 CMS in Europe, and the other leading CMS platforms also have open source licences  17:10 — We4Authors Cluster overview, and its goals  20:23 — Why it's important to include licensed software in accessibility initiatives  27:37 — How this work could influence e-learning (and LMS platforms, too)  28:52 — Let experts focus on making great content instead of worrying about compliance  42:05 — Tools need to be more accessible so people with disabilities can become web authors themselvesResources  Presentation Slide Deck  Presentation Overview  We4Authors  About FunkaConnect with Mike  LinkedIn  GitHub  Drupal  Medium  EmailGovernment Accessibility and the CMSProblem was originally published inCivicActions on Medium, where people arecontinuing the conversation by highlighting and responding to this story.",
      "date"     : "2021-03-12 16:00:00 +0000"
    },
  
    {
      "title"    : "Automated accessibility testing: Leveraging GitHub Actions and pa11y-ci with axe",
      "url"      : "/posts/automated-accessibility-testing-leveraging-github-actions-and-pa11y-ci-with-axe",
      "content"  : "We launched the CivicActions Accessibility practice area and its accompanying website in January 2021.Our intent is for the practice area to be an open project and community for CivicActions team members, and the broader digital government service industry, including clients, partners, government contractors, and generally anyone who wants to improve accessibility on the web.Practicing what we preachWe realized early on that if we were going to be truly inclusive with our work and provide accessibility resources to the broader community, we should strive to make the website as accessible as possible.While we acknowledge that automated testing isn't a panacea, it's one way to address accessibility issues quickly and at scale.Using GitHub and open source technology – general and accessibility-specific – we created a continuous accessibility integration environment that helps us better practice what we preach.Our technology and accessibility "stack"We proudly leverage open source technologies wherever possible, and all of these tools used here meet that criteria.The site is powered by Jekyll and U.S. Web Design System, specifically the U.S. Web Design System Jekyll theme maintained by 18F and the USWDS team. The site is hosted through GitHub Pages.We added automated accessibility testing using GitHub Actions and pa11y-ci with axe.Configuring Jekyll with a sitemap and npmWe recommend adding a sitemap.xml generator to Jekyll which will be used by pa11y-ci to test all pages. We use the jekyll-sitemap plugin.We recommend using npm to manage the pa11y-ci packages and commands. Run npm init command to create the package.json file.Installing pa11y-ci and setting it up to run locallyInstall pa11y-ci as a development dependency with npm.npm i --save-dev pa11y-ciAfter the installation is complete edit the package.json and add the following commands to the "scripts" section:"start-detached": "bundle exec jekyll serve --detach","pa11y-ci:sitemap": "pa11y-ci --sitemap http://localhost:4000/sitemap.xml --sitemap-exclude "/*.pdf""  start-detached: Starts the webserver that will run Jekyll to be used for testing.  pa11y-ci:sitemap: Runs pa11y-ci tests using the sitemap and excludes PDFs.Add a JSON file named .pa11yci which allows you to configure pa11y-ci with various options. Here is our file:{  "defaults": {    "concurrency": 4,    "standard": "WCAG2AA",    "runners": ["axe"]  }}  concurrency: The number of tests that should be run in parallel.  standard: The accessibility standard to use: Section508, WCAG2A, WCAG2AA (default), WCAG2AAA.  runners: The test runners to use: axe (run tests using aXe-core), htmlcs (default,  run tests using HTML CodeSniffer).That's it. You can run this setup locally using npm, and you will see the following output (truncated for brevity):dmundra in ~/workspace/accessibility/accessibility on branch main > npm run start-detached> start-detached> bundle exec jekyll serve --detachConfiguration file: /Users/dmundra/workspace/accessibility/accessibility/_config.yml            Source: /Users/dmundra/workspace/accessibility/accessibility       Destination: /Users/dmundra/workspace/accessibility/accessibility/_site Incremental build: disabled. Enable with --incremental      Generating...                     done in 8.217 seconds. Auto-regeneration: disabled when running server detached.    Server address: http://127.0.0.1:4000Server detached with pid '14850'. Run `pkill -f jekyll' or `kill -9 14850' to stop the server.dmundra in ~/workspace/accessibility/accessibility on branch main > npm run pa11y-ci:sitemap> pa11y-ci:sitemap> pa11y-ci --sitemap http://localhost:4000/sitemap.xml --sitemap-exclude "/*.pdf"Running Pa11y on 49 URLs: > http://localhost:4000/guide/glossary - 0 errors > http://localhost:4000/guide/introduction - 0 errors > http://localhost:4000/guide/history - 0 errors > http://localhost:4000/guide/design - 0 errors...✔ 49/49 URLs passedAs you can see, at the time of this writing we have all our pages passing! To see examples of us fixing reported accessibility issues check out pull request #128 on this site.Note: we have also noticed that pa11y-ci intermittently throws an error when trying to test many pages. Here is an open issue to find a solution to that: issue #128 on the pa11y-ci repository.Running pa11y-ci in a GitHub actionNow that we have it running locally, here is how we configure it to run every time we submit a pull request in GitHub.Add a YML file to .github/workflows folder. We called our version pa11y.yml. Here is our file:name: pa11y testson: [pull_request]jobs:  build:    name: Building site and running pa11y-ci tests    runs-on: ubuntu-latest    steps:      - name: Checkout source.        uses: actions/checkout@v2      - name: Install jekyll site dependencies.        uses: ruby/setup-ruby@v1        with:          ruby-version: 2.6          bundler-cache: true      - name: Install pa11y-ci dependencies.        run: npm install      - name: Start up jekyll server.        run: npm run start-detached      - name: Run pa11y-ci.        run: npm run pa11y-ci:sitemap 2>&1 | tee pa11y_output.txt              - name: Read pa11y_output file.        id: pa11y_output        uses: juliangruber/read-file-action@v1        with:          path: ./pa11y_output.txt              - name: Comment on pull request.        uses: thollander/actions-comment-pull-request@master        with:          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}          message: '<details><summary>Pa11y testing results</summary>```${{ steps.pa11y_output.outputs.content }}```</details>'      - name: Check for pa11y failures.        if: contains(steps.pa11y_output.outputs.content, 'errno 2')        run: |          echo "::error::The site is failing accessibility tests. Please review the comment in the pull request or the pa11y-ci step in the workflow for details."          exit 1From the top, this action is run only on pull requests and uses the ubuntu-latest image. Then the steps will:  Check out the source code.  Install the Jekyll Ruby dependencies but caches them so that subsequent runs can go faster.  Install the pa11y-ci dependencies via npm.  Start the webserver as we did locally.  Run pa11y-ci to test the site and capture the output to a file.*  Read the file to a variable so that we can use it in the next step.*  Send the results of the file to the pull request as a comment in a <details> collapsed element.*  Check the output for failures and "hard fail" the action.** Capturing the output to a file and commenting on the pull request are optional features and could be harder to maintain. You can simply run the pa11y-ci commands and view the results in the action output.Here is an example screenshot of the GitHub action run of pa11y-ci tests (taken from pull request #127 checks):Here is an example screenshot of the comments added to a pull request (taken from pull request #137 comment):SummaryUsing the above steps, you can quickly get your GitHub-hosted Jekyll site automatically tested for accessibility issues, but remember, automatic tests are not a panacea.As noted in our playbook for automated testing:  … no matter the tool, automated testing only catches about one-third of accessibility issues, so it cannot be relied upon to determine if a site complies. To better ensure that their digital tools are accessible to keyboard-only and assistive technology users, automated tests need to be done along with a robust manual testing plan.Further reading and examples  Automated accessibility testing with Travis CI  How to Automate Web Accessibility Testing  Examples of applying the above steps to Jekyll sites:          BBC's "Accessibility, News and You".      GSA's "Accessibility for Teams".      18F Accessibility Guide.        What are other Jekyll sites doing?          The Pa11y website uses Travis CI and pa11y-ci.      The 18F Accessibility Guide uses CircleCI and axe.      Thank you to Melinda Burgess, Luke Fretwell, and Mike Gifford for your support, thoughts, and feedback.What about GitLab?We published a related post on how to do the same automated accessibility testing on GitLab using Pa11y CI and Cypress.",
      "date"     : "2021-03-12 15:00:00 +0000"
    },
  
    {
      "title"    : "Government Technology: How Will Biden Transform Government Website Accessibility",
      "url"      : "/posts/govtech-how-will-biden-transform-government-website-accessibility",
      "content"  : "Government Technology published a guest editorial we wrote on the new Whitehouse.gov accessibility page.From the post:  It's highly encouraging that the new Biden administration is immediately emphasizing the importance of digital accessibility. There appears to be a legitimate commitment from the WhiteHouse.gov team to meet the needs of all people.  The Web team behind the White House site — like all of us who are working to build accessible government digital services — has a significant challenge ahead, but an equally significant obligation to do the hard work and always be improving. The suggestions here for improving the federal website can generally be applied to state and local governments looking to ensure that all citizens can interact with government.  The dawn of the people's government website is upon us.Full post: How Will Biden Transform Government Website Accessibility",
      "date"     : "2021-02-18 16:00:00 +0000"
    },
  
    {
      "title"    : "Improving government accessibility through open source",
      "url"      : "/posts/improve-government-accessibility-through-open-source",
      "content"  : "I shared my thoughts on the CivicActions blog for how agencies can adopt an open source strategy to make their services more usable by people of all abilities.From the post:  As governments seek to make accessibility a priority in today's digital world, it makes sense to start with tools that are purpose-built to evolve along with technology systems and to be part of communities that care deeply about meeting the needs of all users. Open source tools like Drupal and the U.S. Web Design System can help you stay compliant with accessibility regulations, but also to lay a strong foundation for a future in which people of all abilities can more easily benefit from the services you provide.Full post: 4 ways to improve government accessibility through open source",
      "date"     : "2021-02-08 16:00:00 +0000"
    },
  
    {
      "title"    : "GCN: The need for accessibility compliance as code",
      "url"      : "/posts/gcn-accessibility-compliance-as-code",
      "content"  : "GCN (Now called Route-Fifty) published a guest editorial we wrote that was inspired by a conversation we had on a recent CivicActions Accessibility practice area call.From the post:  Baking VPAT into the code-as-compliance process isn't a panacea. But it is a humble beginning to prioritizing accessibility and making a cumbersome process less so. By shifting the mindset and approach to one of open principles, machine-readable accessibility can become equally important to security in the compliance process.Full post: The need for accessibility compliance as code)",
      "date"     : "2021-02-08 16:00:00 +0000"
    },
  
    {
      "title"    : "WhiteHouse.gov: Beginning an accessibility journey",
      "url"      : "/posts/whitehouse.gov-beginning-an-accessibility-journey",
      "content"  : "Praise and recommendations for the accessibility statement published by the new administrationWith the inauguration on January 20, the WhiteHouse.gov team released a newwebsite. A noticeable and well received feature of the new site is that itonce again has an accessibilitystatement which is linked in thefooter of every page — a best practice that demonstrates this administration'scommitment to serving all Americans of all abilities.The short-but-aspirational statement makes it clear that this is just thebeginning, and that the White House team will continue working to build a sitethat is accessible and usable by folks who are challenged by impairments,using assistive devices, or facing situational barriers that make it harder tonavigate online.  The statement serves as an initial step toward making the website, and allservices, accessible to the greatest number of people possible.The statement serves as an initial step toward making the website, and allservices, accessible to the greatest number of people possible. It's clearthat this administration isn't just aiming for compliance with the currentrequirements of the recently-refreshed Section 508guidelines, but going the full extent to align with WCAG 2.1AA — the latest W3Crecommendation and the standard beginning to be adopted by governmentsworldwide.An even better statement: suggestions for improvementWhile the newly released accessibility statement is a laudable first step,it's understood to be a work-in-progress. Everyone working on digital productsand projects for public services should be continually looking foropportunities to make them more accessible, and the White House statementspecifically invites comments on ways to improve. Our recommendations include:Make it easy to get in touchTo make it easier for people to flag problems with the site or give feedback,more ways to get in touch could be offered. There are currently several phonenumbers listed (including some for hearing impaired folks — well done!), but aweb form, email address, or even Twitter account could be added to allow usersto digitally submit ways to improve the site. After all, some people are non-verbal, and others might feel a bit shy about picking up the phone and callingthe White House!Additionally, digital feedback options can capture browser and operatingsystem information and allow people to upload screenshots, which makesdebugging easier. Email and Twitter can be used to gather information into acommon issue queue to manage feedback and make sure that issues are identifiedand fixed in a timely manner.Address the whole White House experienceThe accessibility statement could be expanded to provide users withinformation about the accessibility features of the White House itself, notjust the website. For example, when we are able to do White House tours again,where will visitors go to find out if there is an accessible washroom? Theremay also be mobile apps that fall under the White House management that needto be covered in accessibility considerations. Thinking about all aspects ofservices (digital and physical) can help agencies provide the most holisticaccessible experience to everyone.  Thinking about all aspects of services (digital and physical) can helpagencies provide the most holistic accessible experience to everyone.Account for accessibility limitationsRecognizing that accessibility is a journey that never ends, it's important toacknowledge where there are limitations that impaired people may encounterbreakdowns in accessibility. For example, if users navigate to archivedpages of the website, they will likely find them less accessible than thecurrent pages that are being brought up to an improved standard.Legacy files and videos may also be found lacking in accessibility. Ifthere is published content that isn't accessible but is still being served upto people, the statement can identify it, and explain if there is a processfor requesting that the material be provided in an accessible format.  Recognizing that accessibility is a journey that never ends, it's importantto acknowledge where there are limitations that impaired people mayencounter breakdowns in accessibility.And of course there is the challenge of the ever-beloved-by-government PDFfiles. Will the WhiteHouse.gov team be continuing to use PDF files, orfollowing the model that the UK hasrecommended? If PDFs will be used, is there a plan formaking them accessible, or providing the information in an additional formatthat is accessible? Will large print versions be made available, or only onrequest? These are all questions that can be addressed in a robustaccessibility statement.Show how the sausage is madeAccessibility and transparency are closely linked. There is an opportunityhere to provide visibility into how WhiteHouse.gov is built, which can promotebetter understanding and usability for everyone. The White House could explainthat the site is built with WordPress and that they are following theaccessibility best practicesdefined in the WordPress community. This includes using a plug-in that allowsusers to switch between high/low contrast, as well as change the font size.Many people still don't know about darkmode, or how they can configure it by default in theirbrowser.If the site is built on the United States Web DesignSystem (USWDS), it would be useful tohighlight this. This is a U.S. Government framework that has been extensivelytested for accessibility best practices. It may be worth noting that the WhiteHouse is committed to keeping up with the USWDS and will be applying updatesto this framework to keep up-to-date with security/accessibility bestpractices. If there are deviations from the standard implementation, thiscould be explained.It would be also important to know what is the testing process used internallyin the WhiteHouse.gov team. Are automated tools used? Are new features testedwith people who have lived experience with disability? Does the team test forkeyboard-only users? Has anyone checked what happens to text if someone zoomsin their browser to enlarge 300%? Explaining the extent of testing that hasbeen done will allow people to predict what level of accessibility they mayfind for their own particular needs when using WhiteHouse.gov.Accessibility statement best practicesFor the White House team, and for all of us working to create digital servicesthat are usable by the greatest number of people, there are guidelines tohelp. If any team is looking to start with a robust accessibility statement,they may start with the advice of accessibility expert Denis Boudreau, whosummarized the four essential elements of an accessibilitystatement. Itshould have:  Statement of intention to best serve people with disabilities  Reference to the standards followed (usually WCAG 2.0 AA)  Examples of accessible implementations on their site  How to reach out with comments or requests for helpAccessibility expert Karl Groves outlined alist that adds: "What are you doing tosupport and improve accessibility?" as an important element. Lainey Feingold,a well respected legal accessibility expert, has suggested that an idealaccessibility statement would also includereferences to an organization's accessibility policies and include informationabout other accessibility services. Web accessibility firm Microassistdeveloped a useful checklist for gettingstarted.The W3C has an accessibility statementgenerator whichadds in section for technical information that might help a user betternavigate the site. Disability:IN and the UK's Government DigitalService have also produced some excellent guides. The accessibilitystatement page, perhaps more than any other page, should be kept current sopeople can access accurate information — and of course it should be made asaccessible as possible!A website for all peopleIt is encouraging to see what the new administration has done to emphasize theimportance of accessibility, even in the first weeks after the inauguration.There is a real commitment from the Biden team to meet the needs of allpeople, clearly including the 20% that have disabilities. The web team behindthe White House site — like all of us who are working in support of governmentdigital services — have a significant challenge ahead, but an equallysignificant obligation to do the hard work and always be improving. TheAmerican people deserve no less.WhiteHouse.gov: Beginning an accessibilityjourney was originally published inCivicActions on Medium, where people arecontinuing the conversation by highlighting and responding to this story.",
      "date"     : "2021-02-05 16:00:00 +0000"
    },
  
    {
      "title"    : "Hello world",
      "url"      : "/posts/hello-world",
      "content"  : "Stay tuned. We're just getting started.In the meantime, take a look around:  We're open.  Join us  News",
      "date"     : "2021-01-14 16:00:00 +0000"
    },
  
    {
      "title"    : "4 ways to improve government accessibility through open source",
      "url"      : "/posts/4-ways-to-improve-government-accessibility-through-open-source",
      "content"  : "How agencies can adopt an open source strategy to make their services more usable by people of all abilitiesPhoto by TimMossholderon UnsplashGovernment agencies, of all organizations, have perhaps the greatestobligation to plan for the accessibility of theirwebsites anddigital services. Beyond meeting compliance requirements for accessibility,mission-focused agencies want to make sure the greatestnumber of people — regardless of ability — can use and understand theimportant content and services provided online.There's a tendency to think only of permanently "disabled" people when we talkabout accessibility, but it's an issue that extends to a large portion of thepopulation. Temporary and situational disabilities can affect all of us fromtime-to time — as we find ourselves with an injured hand or out on a sunny daytrying to read our phones. And of course, some of the people that most needgovernment services may also face some of the greatest barriers in accessingdigital content — such as English Language Learner immigrants, low-incomefamilies with limited access to Internet devices, the aging populationreceiving Medicare, or Veterans struggling with mental health challenges.Meeting the needs of people with varying abilities and backgrounds is a multi-layered issue requiring conscious decisions around technology and process inorder to get it right. This means government digital platforms should be builtwith accessibility in mind, using modern tools and practices that willconstantly improve instead of falling out of date.  Meeting the needs of people with varying abilities and backgrounds is amulti-layered issue requiring conscious decisions around technology andprocess.CivicActions has long been a proponent of open sourcetechnologies and agilepractices, which provide many benefits to government agencies, including anaccessibility advantage. Here are four recommendations for an open sourcestrategy that will set agencies up for success in the goal of providing modernand accessible digital services.Use tools that are ready-made for accessibilityIt only makes sense to start on the right foot by using tools that havealready been tested for accessibility — otherwise you are beginning with a lotof technical debt. Your team will be responsible for finding and fixing allthe errors, and continually monitoring anything that's built to make sure thesystems continue to be functional for groups that depend on you foraccessibility (e.g., people who use assistive technologies like screenreaders).Open source platforms such as Drupal (for websitecontent management) and the U.S. Web DesignStandards (USWDS) (for designinggovernment websites) are already evaluated against the newly updated Section508 requirements and have been extensively tested against the World WideWeb Consortium's (W3C) Web Content Accessibility Guidelines 2.0AA. The combination ofthese tools for government websites provides an accessibility boost from theget-go. Accessibility is a complicated issue, so using platforms that arecontinually maintained by the open source community is smarter than trying toapply "quick fixes" to problems as they are discovered — which can put yourorganization at risk.  Open source platforms like Drupal and USWDS are built to meet accessibilitystandards as they evolve.CivicActions engineers and designers have been working on the pairing ofDrupal and USWDS since the design standards were initially released, knowingthese open source tools would be a powerful combination for agencies lookingto bring their systems up to date. From presenting about the benefits of thispairing when building government sites, toco-maintaining a USWDS base theme inDrupal, we're committed to helping agencies make the most of these platformsin their modernization efforts.Choose an agile approachWhether you're modernizing a legacy system, building something new, orimproving current operations, an agile approach is best for keepingaccessibility at the forefront. This is our go-to process for any work withgovernment clients, because the iterative cycles allow barriers to beidentified and resolved early in the process — saving time and money in theend. Agile also pairs well with an open source strategy, because open sourcetools evolve constantly as improvements are made by people who are using them.With all team members working in an agile manner:  Designers can quickly identify potential accessibility problems in their prototypes  Content authors can check for readability (and compatibility with assistive technology)  Developers can use automated accessibility tools to catch issues before code is committed to the repositoryAnd this can all happen before clients even see prototypes, let alone beforehuge systems are put in place that would be time-consuming and expensive tofix if accessibility issues were uncovered later. Our years of experience withopen source tools (especially Drupal) have shown that agile allows forcomprehensive testing at every stage of a project in addition to theopportunity to benefit from work that others have done — which improves theoverall accessibility, security, and usability of technology systems.Plan for the futureThe web is evolving quickly. Browsers, standards, and use-cases change overtime. And agencies will increasingly see people accessing their websites andservices through new technologies that depend on semanticcontent inorder to work well — which adds plenty of layers to the accessibilitychallenge.For example, Google search results glean information about organizations fromstructured site content. The use of assistant technologies like Siri, Alexa,and Google Home will make voice recognition a growing interface to considerfrom an accessibility perspective. And Virtual / Augmented Reality willcontinue to grow in popularity, meaning that government sites will need to beaccessible not just through home browsers, but through mobile devices, cardashboards, home speakers, and other AI.All this means that no "accessibility checklist" will ensure your site meetsits accessibility requirements next year, or in five years. So it's importantto view accessibility as a journey, not a destination. Agencies should planfor the future by establishing a strong foundation that will allow them toevolve their accessibility efforts for years to come — without having to scrapold technologies and start over!  Accessibility is a journey, not a destination.One way to do this is through open source tools like Drupal and USWDS, whichare constantly improved as maintainers and organizations contribute updatesand fixes. As technology evolves, these tools keep up, making it easier tomaintain accessibility over time. That's part of the reason Drupal is trustedby leading disability organizations like the National Federation of the Blind.For government, as well, Drupal provides a platform for managing web contentthat is built for accessibility and will continue to evolve along with theonline behavior of constituents.Be part of the communityCommunity contributions are the driving force that make open source tools soadaptable. Unlike proprietary software that is owned and maintained by oneentity, open source tools are owned by everyone and can be improved by anyone.More government organizations are adopting this open approach to technology asa way to share helpful code with other agencies and the public — while also gaining a communityof support upstream as open source software libraries are continually updated.Particularly with Drupal and USWDS, which are heavily used by government,accessibility improvements are made whenever barriers to users are identified.This makes it easier for all agencies using these tools to implementaccessibility best practices for their web content.  Open source tools like Drupal and USWDS make it easier for agencies toimplement accessibility best practices.CivicActions has cultivated and contributed to open source communities forover a decade. Their teams are actively using and improving Drupal and theU.S. Web Design System, working with agencies to make government services moreaccessible to everyone. Being part of these communities allows developers anddesigners to stay familiar with issue queues, create and test patches, andlearn from others who are using the same systems in different ways — so we canall shape these tools to be as functional, flexible, and useful as possible.As governments seek to make accessibility a priority in today's digital world,it makes sense to start with tools that are purpose-built to evolve along withtechnology systems and to be part of communities that care deeply aboutmeeting the needs of all users. Open source tools like Drupal and the U.S. WebDesign System can help you stay compliant with accessibility regulations, butalso to lay a strong foundation for a future in which people of all abilitiescan more easily benefit from the services you provide.CivicActions delights in helping agencies adapt these tools to betterfulfill their missions. Get in touchto talk about making government services more accessible with a forward-thinking open source strategy.4 ways to improve government accessibility through opensource was originally published inCivicActions on Medium, where people arecontinuing the conversation by highlighting and responding to this story.",
      "date"     : "2020-10-05 16:00:00 +0000"
    },
  
  
    {
      
        "title"    : "Not found (404)",
        "url"      : "/404.html",
        "content"  : "Sorry, we can't find that page. If you entered the address manually, please check your spelling and try again."
      
    },
  
    {
      
    },
  
    {
      
        "title"    : "Accessibility Conformance Report (ACR)",
        "url"      : "/ACR/",
        "content"  : "An Accessibility Conformance Report (ACR) is a document that measures how well  information and communication technology (ICT) products comply with Section 508 Standards. These reports are mainly used in government and education procurement, but can also be used by private sector organizations. During procurement, vendors are encouraged to create an ACR to show how an ICT meets the specific accessibility requirements that are being requested.An ACR is often created using a Voluntary Product Accessibility Template (VPAT), which comes in a few standard formats for reporting accessibility conformance. When evaluating our own work on websites, we use OpenACR along with the VPAT 2.5 WCAG (November 2023) template. OpenACR is a tool developed by CivicActions and maintained by the General Services Administration (GSA). To learn more about its development, read our case study.OpenACR reads and formats ACR results in YAML, a machine-readable format that can be easily stored and updated, and allows accessibility claims of digital products and services to be easily compared. Related to this, the OpenACR web editor provides a step-by-step interface for using OpenACR to create machine-readable ACR documents.Our exampleCivicActions prioritizes creating ACRs to show how the products we use meet accessibility standards set by Section 508. To see an example of how to create an ACR, view the report created for Drupal 9.1.Drupal 9.1 Accessibility Conformance ReportResources  OpenACR web editor  CivicActions OpenACR Case Study  GSA Accessibility Conformance Report (ACR)  Free VPAT and other resources from ITI  How to read a VPAT"
      
    },
  
    {
      
        "title"    : "About CivicActions Accessibility",
        "url"      : "/about/",
        "content"  : "                                            Home                                                                About CivicActions Accessibility                                                                                                                            Meet us                                                Contact us                                                Join us                                                        Who we areCivicActions Accessibility is an open project primarily developed by CivicActions team members.We follow agile process and encourage others to do so as well.We are gathering information that we find useful for our team, and hope that it resonates with our clients and the broader community. We acknowledge that this resource is imperfect, impermanent and incomplete, and we encourage you to help make it better. There is a lot of great information about digital accessibility already freely available on the web. We aim to refer people to great resources, or build upon them.Please let us know what you find helpful, if there are resources we should include or if there are ways we can improve.Our work    Project board    Calendar    Join us                                        "
      
    },
  
    {
      
        "title"    : "Accessibility Statement",
        "url"      : "/accessibility",
        "content"  : "Our goalsThe CivicActions Accessibility website is a work in progress, but as part of this we are attempting to follow the best practices we are documenting.We strive to meet the latest W3C Recommendation of the WCAG guidelines (currently WCAG 2.1 AA).Design frameworkThe design framework for this website is built primarily leveraging the U.S. Web Design System which has undergone extensive accessibility testing. By leveraging open source best practices, we can benefit from much larger teams which have done extensive testing of their patterns.ColorThe website color palette is based on the USWDS color tokens.TechnologyThe pages on this website are primarily written in Markdown which substantially reduces the range of errors available in HTML. These are then compiled using Jekyll and presented to the user as structured HTML5. The site is hosted on GitHub, which has a very broad community of users who are free to to add issues or pull requests.We use axe-core with Pa11y to evaluate that every page follows basic accessibility best practices. Details for this are shared in our blog.Known issues  Open website accessibility issues  We can control the accessibility of the site, but not the accessibility of GitHub. GitHub is reasonably accessible, but is not currently seeking to be as accessible as this site.FeedbackIf you run into any accessibility barriers with this website, please contact us:  Email: accessibility-qa.civicactions.com  Submit an issue  Submit a pull request"
      
    },
  
    {
      
        "title"    : "Agile",
        "url"      : "/agile",
        "content"  : "We are AgileCivicActions Accessibility is an agile project. We use a project board to iteratively make progress on our goals, collaborate on issues, have open discussions, deliver a working site and respond to the changes that happen constantly in the world of accessibility.Accessibility and AgileWe encourage accessibility in every part of agile processes. Examples, adding inclusive user archetypes to design sprints, adding accessibility tests to the definition of done, demonstrating how a product is accessible in sprint reviews, prioritizing accessibility goals in retrospectives, delivering accessible product increments, and much more.Examples of places to encourage adoption of accessibility  Understanding accessibility needs in discovery.          Developing personas/archetypes that represent accessibility questions in design sprints.        Adding accessibility requirements to working agreement/definition of done.  Adding accessibility acceptance criteria to user stories.          Creating specific user stories for permanent, temporary, or situational disabilities.        Using accessibility testing tools:          Developing a feature locally.      Automated testing when pushing code to a branch or infrastructure.      Testing a feature in QA or production.        User accessibility testing after a feature/project delivery.  Doing manual testing.  Reviewing site-wide automated tests.  Reviewing with assistive technology (VoiceOver/NVDA).Examples of our practices  Accessibility Personas  Automated testing"
      
    },
  
    {
      
        "title"    : "Analytics",
        "url"      : "/analytics",
        "content"  : "Websiteaccessibility-qa.civicactions.comWhy we do thisWe believe in open analytics/data and, by sharing this information publicly, we hope that others might learn from our work.AnalyticsNote: This visualization is using third party services (Google Analytics, Google Data Studio), and we are limited in our ability to affect its accessibility conformance."
      
    },
  
    {
      
        "title"    : "Calendar",
        "url"      : "/calendar",
        "content"  : "Calendars  Internal calendarMeetingsCivicActions Practice Area CallBi-weekly open discussion with all CivicActions teams members interested in learning about accessibility and participating in CivicActions Accessibility opportunities.  Meeting notes (Internal)PrioritizationWeekly working call to groom the CivicActions Accessibility project board and determine weekly priorities and assign tasks.Check-insTwice-weekly 15-minute scrum related to CivicActions Accessibility project board tasks.RetrospectivesQuarterly one-hour CivicActions Accessiblity retrospective.Community eventsStay tuned!"
      
    },
  
    {
      
        "title"    : "Colophon",
        "url"      : "/colophon",
        "content"  : "  Design system: U.S. Web Design System  Icons: 18F Visual Identity Icons and Font Awesome  CMS: Jekyll  Host: GitHub"
      
    },
  
    {
      
        "title"    : "Code of conduct",
        "url"      : "/conduct",
        "content"  : "The CivicActions Accessibility community is dedicated to providing a harassment-free experience for everyone, regardless of gender, gender identity and expression, sexual orientation, disability, physical appearance, body size, race, or religion. We do not tolerate harassment of participants in any form.This code of conduct applies to all CivicActions Accessibility sponsored spaces, including our blog, mailing lists, and wiki, as well as any other spaces that CivicActions Accessibility hosts, both online and off. Anyone who violates this code of conduct may be sanctioned or expelled from these spaces at the discretion of the CivicActions Accessibility Anti-Abuse Team.Some CivicActions Accessibility-sponsored spaces may have additional rules in place, which will be made clearly available to participants. Participants are responsible for knowing and abiding by these rules.DefinitionsHarassment includes:  Offensive comments related to gender, gender identity and expression, sexual orientation, disability, mental illness, neuro(a)typicality, physical appearance, body size, race, or religion  Unwelcome comments regarding a person's lifestyle choices and practices, including those related to food, health, parenting, drugs, and employment.  Deliberate misgendering or use of 'dead' or rejected names  Gratuitous or off-topic sexual images or behaviour  in spaces where they're not appropriate  Physical contact and simulated physical contact (eg, textual descriptions like "hug" or "backrub") without consent or after a request to stop.  Threats of violence  Incitement of violence towards any individual, including encouraging a person to commit suicide or to engage in self-harm  Deliberate intimidation  Stalking or following  Harassing photography or recording, including logging online activity for harassment purposes  Sustained disruption of discussion  Unwelcome sexual attention  Pattern of inappropriate social contact, such as requesting/assuming inappropriate levels of intimacy with others  Continued one-on-one communication after requests to cease  Deliberate "outing" of any aspect of a person's identity without their consent except as necessary to protect other CivicActions Accessibility members or other vulnerable people from intentional abuse  Publication of non-harassing private communicationThe CivicActions Accessibility community prioritizes marginalized people's safety over privileged people's comfort. The CivicActions Accessibility Anti-Abuse Team will not act on complaints regarding:  'Reverse' -isms, including 'reverse racism,' 'reverse sexism,' and 'cisphobia' (because these things don't exist)  Reasonable communication of boundaries, such as "leave me alone," "go away," or "I'm not discussing this with you."  Refusal to explain or debate social justice concepts  Communicating in a 'tone' you don't find congenial  Criticizing racist, sexist, cissexist, or otherwise oppressive behavior or assumptionsReportingIf you are being harassed by a member of the CivicActions Accessibility community, notice that someone else is being harassed, or have any other concerns, please contact the CivicActions Accessibility Anti-Abuse Team. If the person who is harassing you is on the team, they will recuse themselves from handling your incident. We will respond as promptly as we can.This code of conduct applies to CivicActions Accessibility sponsored spaces, but if you are being harassed by a member of the CivicActions Accessibility community outside our spaces, we still want to know about it. We will take all good-faith reports of harassment by CivicActions Accessibility community members, especially bloggers, seriously. This includes harassment outside our spaces and harassment that took place at any point in time.The abuse team reserves the right to exclude people from the CivicActions Accessibility community based on their past behavior, including behavior outside CivicActions Accessibility spaces and behavior towards people who are not in the CivicActions Accessibility community.In order to protect volunteers from abuse and burnout, we reserve the right to reject any report we believe to have been made in bad faith. The CivicActions Accessibility Anti-Abuse Team is not here to explain power differentials or other basic social justice concepts to you. Reports intended to silence legitimate criticism may be deleted without response.We will respect confidentiality requests for the purpose of protecting victims of abuse. At our discretion, we may publicly name a person about whom we've received harassment complaints, or privately warn third parties about them, if we believe that doing so will increase the safety of CivicActions Accessibility members or the general public. We will not name harassment victims without their affirmative consent.ConsequencesParticipants asked to stop any harassing behavior are expected to comply immediately.If a participant engages in harassing behavior, the CivicActions Accessibility Anti-Abuse Team may take any action they deem appropriate, up to and including expulsion from all CivicActions Accessibility spaces and identification of the participant as a harasser to other CivicActions Accessibility members or the general public."
      
    },
  
    {
      
        "title"    : "Contact Us",
        "url"      : "/about/contact",
        "content"  : "We love helping people improve accessibility in their products and services. Tell us about your accessibility challenge or reason for contacting us, and we'll get in touch.            Email address*                        How can we help you?*                SubmitMore ways to reach us  Email: accessibility-qa.civicactions.com  LinkedIN: @civicactions  X: @civicactions  Visit our main website: CivicActions.comFeedbackBugs? Comments? Suggestions? We welcome your feedback and ideas for our site.Submit a Github issue"
      
    },
  
    {
      
        "title"    : "CivicActions Accessibility Guide",
        "url"      : "/guide/",
        "content"  : "                                                                                                                                                                                    Introduction                                                                                                                                                                                                                History                                                                                                                                                                                                                Identity and language                                                                                                                                                                                                                Plain language                                                                                                                                                                                                                Tools                                                                                                                                                                                                                Design systems                                                                                                                                                                                                                Accessible documents                                                                                                                                                                                                                Social media                                                                                                                                                                                                                Events                                                                                                                                                                                                                Organizations                                                                                                                                                                                                                Training/certifications                                                                                                                                                                                                                Resources                                                                                                                                                                                                                Semantic HTML                                                                                                                                                                                                                Glossary                                                                                                                                                                                                                Onboarding                                                                                                                                                                                                                Champions program                                                                                                                                                                                                                Accessibility bug classification                                                                                                                                    "
      
    },
  
    {
      
        "title"    : "Holistic Enterprise Accessibility Review Technique (HEART)",
        "url"      : "/heart",
        "content"  : "AboutTo build a holistic delivery system that ensures government digital services are accessible to everyone.  Deck  DocumentChallenge.gov websites are not accessibleProblem  Dated policies/practices  Not baked into procurement  Legacy technology/tools  Limited accessibility proficiency  No culture of accessibilitySolution  Ensure policies follow best practices  Embrace accessible procurement  Use inclusive tools and frameworks  Invest in staffing/training  Build a network of championsOur ProcessStakeholdersAll members of a team play a role in accessibility. Executives, procurement officers, developers, product/project managers, operations, design teams and content authors all need to be engaged.HolisticHEART addresses the following organization issues: policy, procurement, technical, resourcing and culture. We provide concrete improvements to internal processes and leave teams with artifacts that will make implementing accessibility easier.Phases  Scan  Discover  Review  Recommend  ImplementScan  Conduct organization-wide accessibility scans  Implement initial review to identify accessibility barriers  Identify accessibility tools and common digital frameworks  Provide raw data from the scans for further analysis  Aggregate accessibility findings and related observationsDiscover  Interview digital teams to understand stakeholders' processes  Identify common experiences and challenges  Aggregate additional accessibility resources  Highlight strengths and weaknesses of the teamReviewPolicy  Examine organizational policy and procedures  Document accessibility work for Diversity, Equity & Inclusion  Ensure clear responsibilities in existing policies  Compare findings with global best practices  Engage digital stakeholders in reviewing recommendationsTechnology  Identify available accessibility software to digital team  Review accessibility in continuous integration processes  Check for organization-wide accessibility monitoring tools  Improve authoring tools to support content creators  Engage designers and developers in the findingsRecommend  Aggregate findings into a comprehensive report          create tailored recommendations based on findings      list improvements in policies and technology based on reviews        Highlight ways to promote accessibility throughout the organization          provide concrete ways to build accessibility into the culture      suggest appropriate training options for key staff      Implement  Strategize: define next steps in your accessibility journey  Train: build accessibility confidence within your team  Coach: support all digital roles to incorporate accessibility  Deploy: establish an evergreen approaches to remove barriers  Monitor: ensure your organization continues to improveLearn More  Contact: CivicActions Accessibility Team, accessibility-qa.civicactions.com"
      
    },
  
    {
      
        "title"    : "Get accessibility help",
        "url"      : "/help",
        "content"  : "Have questions about accessibility? We're here to help.  Search the site  Visit our guide and playbook  Start a discussion  Email   Working for CivicActions already? Message @accessibility-team in the CivicActions Slack"
      
    },
  
    {
      
        "title"    : "Home",
        "url"      : "/",
        "content"  : "Get startedLearn and contribute to CivicActions Accessibility.Join us"
      
    },
  
    {
      
        "title"    : "News",
        "url"      : "/news/",
        "content"  : "Five reasons to get excited about governmentwide Section 508 assessment criteriaAugust 8, 2023Treat accessibility issues as bugs, not feature requestsAugust 8, 2023How OMB can improve .gov accessibilityMay 5, 2023Daniel Mundra: Diving into DrupalApril 10, 2023Helping disabled Veterans Check-In: Designing an Accessibility MapApril 6, 2023Opensource.com: How I do automated accessibility testing for my websiteOpensource published a guest editorial we wrote on automated accessibility testing.March 2, 2023Mike Gifford gave a presentation at FOSDEM on Accessibility & Open SourceMike gave a talk in Brussels at the annual FOSDEM conference. He focused on how open source is key to building a more inclusive world.February 5, 2023Mike Gifford Presented in at Inclusive Design & Accessibility Meetup in the NetherlandsFebruary 1, 2023Daniel Mundra interviewed on the Talking Drupal podcastA discussion about Automated A11y Testing with Nightwatch.January 16, 2023Mike Gifford & Daniel Mundra interviewed on the Talking Drupal podcastA discussion about Accessibility Scanning & Testing in Drupal.May 31, 2022CivicActions Accessibility PledgeOur committment to accessibility is encapsulated in this pledge.May 19, 2022How Drupal helps us bake accessibility into every projectDecember 13, 2021CivicActions creates Open Product Accessibility Template (OPAT) with the GSACivicActions' contract with the GSA has allowed us to build a open Accessibility Conformance Report that is machine-readable Open Product Accessibility Template (OPAT).August 13, 2021CivicActions wins contract to produce a machine-readable Voluntary Product Accessibility Template® (VPAT®)CivicActions is building the foundation for a new way to approach Accessibility Compliance Reporting with our work with the GSA.August 11, 2021What we learned about accessibility by scanning more than 2 million federal .gov web pagesCivicActions scanned over 2 million federal .gov pages for accessibility barriers and this is what we found.July 30, 2021HEART: Ensuring government digital services accessibilityHolistic Enterprise Accessibility Review Technique is a proactive, interactive process to ensure government digital services are accessible to everyone.June 1, 2021Plain language page added to CivicActions Accessibility GuideThis includes quick tips, tools and community information.May 28, 2021Social media page added to CivicActions Accessibility GuideThis includes tips for text, hashtags, images, video, emoji and related resources.May 27, 2021How we scale inclusive website content with automated testing and open source toolsUsing GitHub and open source technology -- general and text-specific -- we created a continuous text feedback mechanism to help ensure our content mirrors our values.May 25, 2021Open analytics on the CivicActions Accessibility websiteAdding public website analytics to CivicActions Accessibility.May 24, 2021Pre-GAAD event: Authoring tools with built-in accessibilityMay 20, 2021Launching a community of practice for accessibility in government servicesMay 20, 2021Q&A with Mike Gifford: Accessibility in civic techMay 6, 2021Smashing Magazine: 'How To Bake Layers Of Accessibility Testing Into Your Process'April 27, 2021CivicActions Accessibility Guide now availableThe first iteration of the CivicActions Accessibility Guide is now available for public use.April 15, 2021CivicActions Accessibility Playbook now availableThe first iteration of the CivicActions Accessibility Playbook is now available for public use.April 14, 2021Mike Gifford interviewed on the AT Banter PodcastAn entertaining discussion with the Banter crew and Mike Gifford.March 30, 2021Government Accessibility and the CMS ProblemMarch 12, 2021Automated accessibility testing: Leveraging GitHub Actions and pa11y-ci with axeUsing GitHub and open source technology -- general and accessibility-specific -- we created a continuous accessibility integration environment that helps us better practice what we preach.March 12, 2021Government Technology: How Will Biden Transform Government Website AccessibilityGovernment Technology published a guest editorial we wrote on the new Whitehouse.gov accessibility page.February 18, 2021Improving government accessibility through open sourceHow agencies can adopt an open source strategy to make their services more usable by people of all abilities.February 8, 2021GCN: The need for accessibility compliance as codeGCN published a guest editorial we wrote that was inspired by a conversation we had on a recent CivicActions Accessibility practice area call.February 8, 2021WhiteHouse.gov: Beginning an accessibility journeyFebruary 5, 2021Hello worldWelcome to CivicActions Accessibility.January 14, 20214 ways to improve government accessibility through open sourceOctober 5, 2020"
      
    },
  
    {
      
        "title"    : "Join us",
        "url"      : "/about/join",
        "content"  : "Already working for CivicActions?  Join the #accessibility CivicActions Slack channel (CivicActions Internal)  Submit an 'Add new team member' issue (Join GitHub if you haven't already)  Join the meetings (check-ins + prioritization + practice area calls)Not yet working for CivicActions  Add to the issue queue  Help us edit pages and submit pull requests  Follow us on Twitter  Keep watching for opportunities"
      
    },
  
    {
      
        "title"    : "License",
        "url"      : "/license",
        "content"  : "This work is licensed under Creative Commons Attribution-ShareAlike 4.0 International License)."
      
    },
  
    {
      
        "title"    : "OKRs",
        "url"      : "/okrs",
        "content"  : "Presently being developed internally - working doc - (CivicActions Internal)Objectives  TBDKey results  TBD"
      
    },
  
    {
      
        "title"    : "Open",
        "url"      : "/open",
        "content"  : "We work in the openCivicActions Accessibility is an open, agile project and community. We work iteratively, in public. Making the digital world accessible by default is a wicked problem, where the only way we will be able to keep up with the rate of change is if we collaborate together.Our work  Project board  CalendarOur projectsOpen source accessibility projects CivicActions contributes to:  USWDS Color Tool (CivicActions Project)  USWDS  Drupal"
      
    },
  
    {
      
        "title"    : "People",
        "url"      : "/about/people/",
        "content"  : "                                                                                                                                                                                                                                Daniel Mundra                                                                                                                                                                                                                                                                                                                                                                Jack Haas                                                                                                                                                                                                                                                                                                                                                                Jonathan Bourland                                                                                                                                                                                                                                                                                                                                                                Mike Gifford                                                                                                                                                                                                                                                                                                                                                                Nira Datta                                                                                                                                                                                                                                                                                                                                                                Vanessa Luxen                                                                                                                                                                                "
      
    },
  
    {
      
        "title"    : "CivicActions Accessibility Personas",
        "url"      : "/personas/",
        "content"  : "                                                                                                                                                                                    Accessibility Avery                                                                                                                                                                                                                Designer Darcy                                                                                                                                                                                                                Engineer Emery                                                                                                                                                                                                                Procurement Parker                                                                                                                                                                                                                QA Quincy                                                                                                                                                                                                                Remote Raz                                                                                                                                    "
      
    },
  
    {
      
        "title"    : "CivicActions Accessibility Playbook",
        "url"      : "/playbook/",
        "content"  : "                                                                                                                                                                                    Follow Global Initiatives                                                                                                                                                                                                                                Invest in Accessibility Training                                                                                                                                                                                                                                Join the Global Accessibility Community                                                                                                                                                                                                                                Implement Automated Testing                                                                                                                                                                                                                                Do Manual Testing                                                                                                                                                                                                                                Test with Assistive Technology                                                                                                                                                                                                                                Update Accessibility Statements                                                                                                                                                                                                                                Include People with Disabilities                                                                                                                                                                                                                                Build Community of Practice                                                                                                                                                                                                                                Avoid PDF Documents                                                                                                                                                                                                                                Accessible Documents                                                                                                                                                                                                                                Use Checklists                                                                                                                                                                                                                                Improve Authoring Tools                                                                                                                                                                                                                                Provide Role Based Evaluations                                                                                                                                                                                                                                Support Personalization                                                                                                                                                                                                                                Encourage Accessible Distributed Teams                                                                                                                                                                                                                                Consider AI & IA                                                                                                                                                    "
      
    },
  
    {
      
        "title"    : "Projects",
        "url"      : "/projects/",
        "content"  : "                                                                                                                                                                                    USWDS Color Tool                                                                                                                                                                                                                U.S. Web Design System                                                                                                                                                                                                                Drupal                                                                                                                                    "
      
    },
  
    {
      
        "title"    : "Roles",
        "url"      : "/roles/",
        "content"  : "                                                                                                                                                                                    Executive                                                                                                                                                                                                                Procurement                                                                                                                                                                                                                Developer                                                                                                                                                                                                                Product manager                                                                                                                                                                                                                Project manager                                                                                                                                                                                                                Operations                                                                                                                                                                                                                Designer                                                                                                                                    "
      
    },
  
    {
      
        "title"    : "Search",
        "url"      : "/search",
        "content"  : "                                                                            Enter Search Term(s):                                                                                                                                                "
      
    },
  
    {
      
        "title"    : "Services",
        "url"      : "/services",
        "content"  : "CivicActions is a digital agency with the goal to **transform the way governments procure, develop, and deliver digital services**. We've outlined our approach and learn about the broad range of services we offer at [CivicActions our central website](https://civicactions.com/approach). CivicActions has deep experience with open source software and agile development - both lend themselves to great accessibility practices. Our goals are audatious, but we have a talented team and aren't working in isolation. Because we are actively invovled in open communities, we are able to draw on and contribute to a vibrant, evolving ecosystem. This is necessary, if we are going to ensure that we are able to support our clients in building digital content that is more accessible today than it was yesterday. ## Basic servicesWe do offer training, technical reviews and monitoring services. We have considerable experience with remediating sites built on open source technology like Drupal. Collectively our team has over 500 years of experience with the Drupal community. Our team has played a key role in seeing that this Content Management System (CMS) is a leader in accessibility. We're involved in many other open source projects, and have have extensive experience leveraging open source communities to help our clients accomplish their needs. For any organization seeking to implement consistent, secure, user friendly and accessible experiences, open source provides unparralled flexibility. Very few organizations have our level of experience in maximizing usage of open source approaches to problem solving. We can help your software development teams bring accessibility into every sprint so that accessibility solutions are cheaper and more robust. By building accessibility into our process we can ensure that there aren't compliance surprises at the end of the project. ## Holistic approachesWe like to begin all of our accessibility work with an extensive discovery process that allows us to get a high-level perspective of the organization's accessibility maturity. This systems approach to accessibility includes user research and policy/practice evaluation so we can help your team identify the barriers in your site today, as well as to avoid the ones that otherwise would be introduced tomorrow. Borrowing from the best practices of Service Design, we know that giving people the right incentives and examples, is as important as having good tools and templates. Our team has a unique methodology to bring our deep technical understanding to build organization-wide strategies to embrace accessibility. The technical challenges of accessibility will only be addressed when we have accessibility confident organizations. Get in touch if you are interested in learning more - [accessibility-qa.civicactions.com](mailto:accessibility-qa.civicactions.com)."
      
    },
  
    {
      
        "title"    : "Topics",
        "url"      : "/topics/",
        "content"  : "                                                            {% include topic.html %}                                        "
      
    },
  
    {
      
    },
  
    {
      
    },
  
    {
      
    },
  
    {
      
    },
  
    {
      
    },
  
    {
      
    },
  
    {
      
    },
  
    {
      
    },
  
    {
      
    },
  
    {
      
    },
  
  
    {
      
        "title"    : "Allison Carroll",
        "url"      : "/about/people/allison-carroll",
        "content"  : ""
      
    },
  
    {
      
        "title"    : "Civicactions",
        "url"      : "/about/people/civicactions",
        "content"  : ""We help government deliver better public services through modern technology and design.""
      
    },
  
    {
      
        "title"    : "Daniel Mundra",
        "url"      : "/about/people/daniel-mundra",
        "content"  : "Daniel Mundra is a team member of CivicActions Accessibility. He works with co-workers on improving how accessibility testing is included in our projects and community. He set up automated testing on the CivicActions Accessibility website using Pa11y CI, cypress, axe, and GitHub actions. Daniel advocates for automated testing and also shares solutions with colleagues outside of CivicActions for example the General Services Administration's 18F team."
      
    },
  
    {
      
        "title"    : "Jack Haas",
        "url"      : "/about/people/jack-haas",
        "content"  : "Jack Haas is a team member of CivicActions Accessibility."
      
    },
  
    {
      
        "title"    : "Jennifer Houde",
        "url"      : "/about/people/jennifer-houde",
        "content"  : "Jennifer Houde was a team member of CivicActions Accessibility."
      
    },
  
    {
      
        "title"    : "Jonathan Bourland",
        "url"      : "/about/people/jonathan-bourland",
        "content"  : "Jonathan Bourland is a team member of CivicActions Accessibility."
      
    },
  
    {
      
        "title"    : "Luke Fretwell",
        "url"      : "/about/people/luke-fretwell",
        "content"  : "Luke Fretwell was a contributor to CivicActions Accessibility, and is the co-founder and CEO of the digital government platform, ProudCity."
      
    },
  
    {
      
        "title"    : "Michelle Kang",
        "url"      : "/about/people/michelle-kang",
        "content"  : "Michelle Kang was a contributor to CivicActions Accessibility."
      
    },
  
    {
      
        "title"    : "Mike Gifford",
        "url"      : "/about/people/mike-gifford",
        "content"  : "Mike Gifford is a CivicActions Accessibility team member and a Drupal Core Accessibility Maintainer. He has been actively involved in the accessibility unconference community and founder of Ottawa's A11yYOW meetup. He's also a certified IAAP WAS (Web Accessibility Specialist) and has completed the DHS Section 508 Standards for Web certification."
      
    },
  
    {
      
        "title"    : "Nira Datta",
        "url"      : "/about/people/nira-datta",
        "content"  : "Nira Datta is a team member of CivicActions Accessibility."
      
    },
  
    {
      
        "title"    : "Vanessa Luxen",
        "url"      : "/about/people/vanessa-luxen",
        "content"  : "Vanessa Luxen is a team member of CivicActions Accessibility."
      
    },
  
  
    {
      
        "title"    : "Screen reader testing",
        "url"      : "/playbook/AT",
        "content"  : "Screen reader users navigate and experience web pages differently than non-screen reader users typically do. While it takes considerable experience to use a screen reader in the same way as the average daily user, incorporating basic screen reader testing into your accessibility test plan can still be quite effective in finding potential issues.There is considerable variation, even within the blind and low vision community, on how screen reader users navigate the web due to the wide range of vision related disabilities and technologies available. Each screen reader also has different default functionality and behaviors and can be customized to the user's preferences. It's recommended to test with multiple screen readers and devices to account for as many of these variations as possible.Common screen readers  JAWS (Job Access With Speech)          A very popular screen reader available for PC      Requires a paid license to be run      For testing purposes, JAWS can be run in 40 minute intervals without a license        NVDA (Non-Visual Desktop Access)          Another popular option for PC      Free screen reading software that does not require a license        VoiceOver          All Apple products come with VoiceOver by default      VoiceOver is typically more popular as a screen reader for mobile rather than desktop        TalkBack          All Android devices come with this screen reader by default      Not extremely popular overall, but is the most popular for Android devices      Basic screen reader testsUsing at least one of the common screen readers mentioned, complete the basic testing steps.  Read through the web page start to finish.          Is everything read on the page that you expected? Is anything skipped or read in an incorrect order?      Are all elements read in a way that is understandable?        Tab through the webpage using the keyboard.          Are all the interactive elements on the page available using the keyboard?      Does each element respond to expected keys? WebAim has a good reference for expected keyboard interaction.        Confirm use of landmarks to create the main document structure of the page.          Review the landmarks list to see which landmarks/semantic layout elements are used on the page.      Confirm that any duplicate landmarks or regions have been identified with a unique label.        Fill out and submit all forms.          Are all field labels, instructions and hint text, announced as expected?      Are error messages announced and understood?      Are the invalid fields clearly marked?        Confirm that links and buttons appear in the appropriate list within the screen reader menus and have descriptive, unique text labels.  Review all images and other non-text content to confirm they have meaningful alternative text descriptions.ResourcesThese resources and guides can help you to become familiar with and learn how to use each screen reader.  JAWS keyboard shortcuts  NVDA keyboard shortcuts  VoiceOver keyboard shortcuts  VoiceOver touch device gestures  Getting started with TalkBack"
      
    },
  
    {
      
        "title"    : "Consider AI & IA",
        "url"      : "/playbook/ai-and-ia",
        "content"  : "Artificial Intelligence (AI) is already being used in places to help people with disabilities. It has provided very useful as a means to include people with hearing loss in Google Meet, Microsoft Teams and now Zoom meetings, as well. There are many applications which are proving useful for people who are blind, low vision or those who are color blind. There are ways that it could be used to support people with all forms of disability.On the other hand, there are a lot of AI projects which are making bold claims which exaggerate what they can actually do, and where it is possible to actually hurt people with disabilities. A popular example is the AccessiBe widget that boldly claims to use AI to make your website WCAG 2.1 AA compliant, while failing to do so. AI Image recognition for alt text is another example, where people are hoping to simply replace the human effort of writing a meaningful alt text.Jutta Treviranus has pioneered many important inclusion initiatives, and her work on AI is no exception. The edge cases are always going to be at a higher risk of being misunderstood while using machine learning. We need to shift our design approaches from merely satisfying 80% of the users, to build for the fringe. As with other minorities groups, people with disabilities are often disadvantaged with biased data.We can use machine learning to support accessibility, but in many cases it is better to approach it from the approach of Intelligence Augmented (IA). How do we use AI to support authors to produce better content. Perhaps it is by suggesting alt text for the author to review and modify (if needed). AI can also look for patterns in larger datasets than people can process to look for errors that a human would find difficult to pick out.Key questions  What algorithms are you using in your organization?  Have those been assessed for bias?See also  The Ethics of Inclusive AI by Mike Gifford and Emily Ryan"
      
    },
  
    {
      
        "title"    : "Improve authoring tools",
        "url"      : "/playbook/authoring",
        "content"  : "Many of the accessibility errors on the web are accidentally produced by unsuspecting content editors. With the right processes and tools in place, we can make it easier to produce accessible content—and harder to publish inaccessible content.To start to address this issue, the EU recently commissioned Funka—a Swedish accessibility firm—to conduct a pilot called We4Authors on web authoring tools, producers and communities. The pilot evaluated several different Content Management Systems (CMS), including Drupal, to find ways to increase accessible publishing practices. What became clear, is that CMSs are currently contributing more to the problem than most are aware, by overlooking providing authors with support they need to produce accessible content. Many errors are a result of author inputs in the WYSIWYG editor (TinyMCE, CKEditor, etc), and most web authors are not accessibility experts and so do not know the best practices to publish accessible content in their CMS. Most authors are not accessibility experts, and few have the time to go through the additional steps necessary to create accessible content.We4Authors demonstrates that many content producers and suppliers claim to deliver accessible content, many just don't understand accessibility. To make matters worse, CMSs are often not built from the author's perspective, which makes it hard to create accessible content and forces authors to navigate unintuitive publishing interfaces. Having a pleasant authoring experience isn't just a perk—it can greatly facilitate the production of accessible content—but unfortunately it's usually overlooked.The Authoring Tool Accessibility Guidelines (ATAG) 2.0—a W3C Recommendation in 2015—is the most comprehensive approach to address the accessibility of authoring tools. Part A of the guidelines addresses the authoring interface to ensure that it too meets WCAG requirements, and Part B aligns directly with the goal of supporting authors in producing accessible content.Drupal 8 has worked to achieve many elements of both parts for ATAG 2.0 AA. More than any other popular CMS, Drupal's authoring environment is well-positioned to support authors with disabilities. Drupal has also implemented many measures to update the authoring experience and ensure more inclusive patterns are available to authors by default.ATAG 2.0 Part B identifies where a CMS can help authors create more accessible content. This doesn't remove the need for training, but should make it easier for people to implement best practices consistently. Government employees can't all be expected to be accessibility experts, but we can and must provide them with the right tools for creating accessible content.Checklist  Work to see that the authoring interface is accessible.  Feature ATAG 2.0 requirements as part of new technology procurement.  Simplify the authoring interface to make it easier for authors to make accessible content.  Include links to accessibility guidelines in help text where appropriate.Key questions  Are alt texts required? Can this be over-ridden for decorative images?  Are heading tags used semantically to describe the structure of the content?  Are authors given help on how to create accessible content (ie. how to write good alt text)?"
      
    },
  
    {
      
        "title"    : "Implement automated testing",
        "url"      : "/playbook/automated-testing",
        "content"  : "OverviewAutomated testing can occur at different layers of the process of creating digital content:  Developers can run automated checks as part of their continuous integration (CI) process  Everyone can look at the accessibility of a single page  Editors can be given accessibility issues within a WYSIWYG editor  Whole websites can now be regularly crawled for bugs  Designers can evaluate problems with contrast issues in their designsAll of this is now possible with a range of proprietary and open source tools. With the rapid development of automated testing, there are now multiple options to gather information on a single website—or an entire government.A guide to automated testingChecklist  Continuous Integration tests incorporate accessibility tools like axe and errors block commits.  Patterns and pages are regularly reviewed to see that they test patterns available to authors.  Site-wide scans are used to track errors over time and catch both common and weird issues.  Creators of digital content all have some browser extension to quickly evaluate page-level accessibility.Key questions  Are you using a variety of automated testing tools to help identify potential problems?  How are you ensuring that you aren't relying too heavily on automated tests?  Have automated processes been set up to optimize use of developer time?Use Deque's aXe toolDeque's aXe has changed the playing field for site reviews. Because of its flexible design, it can be executed from the command line, from within the browser, or even from a WYSIWYG editor. Being executed from the command line means that it is much easier to simply add accessibility checking to any scripts that are being run. It can be appended to a script crawling to ensure security best practices are maintained, or simply added to a continuous integration script.Axe also provides highly structured and easily actionable error reports. These empower entities to pinpoint and categorize issues—from alt text to problems with the symantec structure and missing language. Axe is also already incorporating elements of WCAG 2.1.The Axe accessibility engine is now built into Google's Lighthouse, Microsoft's Accessibility Insights, and a host of other projects. Axe can also be applied to the web, Android and Windows testing. This provides a huge amount of flexibility for most software development teams.Government Digital Services in both the United Kingdom and Singapore have leveraged Deque's open-source axe-core accessibility engine to create tools that crawl and gather accessibility barriers for both public-facing websites and internal web-based communications. Similar open-source accessibility engines have been built by IBM & Deque, and there are proprietary tools available from firms like WebAim, Tenon & Siteimprove.Automated testing caveatHowever, it is important to note that, no matter the tool, automated testing only catches about one third of accessibility issues, so it cannot be relied upon to determine if a site complies. To better ensure that their digital tools are accessible to keyboard-only and assistive technology users, automated tests need to be done along with a robust manual testing plan.CivicActions ApproachCurrently CivicActions uses the following approaches that are open source.Pa11y CIPa11y CI is a continuous integration (CI) runner that can test a few pages or an entire site for accessibility issues. Our projects include Pa11y CI in their CI pipelines and generate reports as artifacts or comments with the results of the testing.We are currently testing this accessibility site using Pa11y CI and we blogged about it here and on opensource.com.Pa11y by default uses the HTML_CodeSniffer accessibility engine, but it is recommended to switch to Pa11y with axe, which is described in this UK Government Accessibility Manual.Cypress testing with the axe coreCypress is a JavaScript testing framework that is used for automated testing. Axe core is a popular accessibility testing engine. Our projects use cypress with the axe core to test components for accessibility issues.Take a look at Setting up Cypress with axe for accessibility article that illustrates the setup. We have that set up and running against the accessibility site.List of popular automated testing tools  Wave  Tenon  SiteImprove  See more tools on our dedicated tools page"
      
    },
  
    {
      
        "title"    : "Using checklists in an accessibility strategy",
        "url"      : "/playbook/checklists",
        "content"  : "The purpose of an accessibility checklist is to help identify accessibility issues in your product, website, or document. However, incorporating checklists into an accessibility strategy can often be tricky. One of the most common pitfalls when using or thinking about checklists is making sure you don't get stuck in a limited compliance mindset. There is no single checklist that covers all possible accessibility issues and as Intopia warned, a checklist mentality can actually be harmful for inclusion. That said, if approached as part of a broader strategy, they can be very helpful when used thoughtfully. Access Armada has some interesting suggestions on more strategic approaches to checklists.What makes a good accessibility checklist  The checklist should build on automated testing approaches.  Provide role-based checklists so that different people in the organization are focused on different aspects of accessibility.  Checklists should be short, concise and easily understood by the majority of the team.  Allow for iteration of the checklists is needed - they may need to change depending on the element or learnings after going through the process a few times.Example checklistsSometimes, you don't need to reinvent the wheel. If there's already an existing checklist available, you can customize it to fit the needs of your team and product. Below are a few examples of existing accessibility checklists:  W3C's Web Accessibility Initiative (WAI)          Basic checklist, not designed to be fully robust but rather to give you a starting point        18F - USA Government          Checklist geared toward US federal websites        A11yProject          Robust checklist using WCAG criteria and broken update into element categories (e.g. Content, Images, etc.) with understandable action items        Heydon Works          Checklist that includes not just items regarding accessibility but other inclusive design checks as well - device support, language, etc.        VoxMedia          Checklist broken down into categories for various practices area/role        Intopia's Accessibility Not-Checklist          This checklist can be customized directly on the site by specific WCAG standards and it can be filtered to display items by either topic or role      Create your own checklistWhile there are many checklists already out there and that can be customized to fit your needs, you don't necessarily need to use something preexisting. Using an existing automated scanning tool, you could create your own simple checklist process.For example, using a tool like WebAim's WAVE, organizations could create a checklist to:  Scan the page with the WAVE scanning tool. View the details tab of the results console:          Review each error - designated by a red box with an X      Review each alert - designated by an orange triangle with an exclamation point        Do manual testing of the page  Evaluate the page for plain language using free tools like the HemingwayApp.Next stepsWhen you are ready to learn more, here are some further guides and resources that may help:  Manual testing  Automated testing"
      
    },
  
    {
      
        "title"    : "Join the global accessibility community",
        "url"      : "/playbook/community",
        "content"  : "There is a vibrant community of accessibility advocates on the internet. This is a group dedicated to inclusion, so it is easy to join. There is so much to learn, and digital accessibility best practices are constantly changing. There is no course or certificate that will give you access to everything your organization needs to be compliant with the law. It takes a community of people to work collectively to find or establish better practices for your website.You can find people interested in accessibility in whatever piece of the internet you are most comfortable using. There is a /accessibility subreddit or web-a11y Slack channel, but there are similar groups in Facebook and LinkedIN too. Most of these are open. If you are part of a software community like Drupal, there are likely many ways to engage with accessibility people in that space, like an #accessibility channel in whatever messaging platform is used.The UK's Government Digital Service has proven regular inter-agency leadership on accessibility in government. If you work for a government agency in the United Kingdom, you can join this group. They now have thousands of cross government accessibility community meetups and a Slack channel for government employees to talk about accessibility. They have gone so far as to build it into their Service Manual.In isolation it is difficult for any one individual to get accessibility right, and maintain it over time. It really is important to find ways that multiple people within an organization or across related organizations, can have a community to lean on. The Section508.gov's Technology Accessibility Playbook includes a play on collaborating with the federal accessibility community.Look outside and see where you can draw from outside of your team or department.Checklist  Collect best practices implemented by other teams.  Sign up to some great free accessibility content available online.  Follow some of the amazing accessibility leaders on Twitter.Key questions  Does the organization know who has experience or interest in accessibility?  Is there a disability working group for staff who have disabilities?"
      
    },
  
    {
      
        "title"    : "Encourage accessible distributed teams",
        "url"      : "/playbook/distributed-teams",
        "content"  : "CivicActions is proudly a distributed team. For over 15 years we have been working remotely with staff around the world, working effectively online. Working virtually allows some people with disabilities to excel. Often people with physical disabilities face barriers in traditional office environments which may not be able to provide an accessible office or sufficient accommodations to participate equally. By using video conferencing, slack, email and other online collaboration tools, our team is able to use a more customized workspace at home, and skip the need to commute to a central office.Unfortunately, there are also people with disabilities which are excluded from participating in many distributed teams. Many deaf and hard of hearing people find it more difficult to read lips or intentions through video conferencing tools. Blind users are blocked by the many visual organization tools like Trello & Mural that do not have good support for blind users. Many websites do not have sufficient support for even keyboard only users.Fortunately, there are things that we can do to change this. Most popular video conferencing tools now offer AI driven speech to text captioning. This isn't perfect, but is continuing to improve. There is more pressure for visual kanban & sticky note tools to build in greater accessibility. More people are thinking about accessibility before buying IT for their office.Another approach that some organizations are doing is helping to assign a minder to help people with disabilities navigate systems that are not fully accessible. Often simply being able to DM a colleague to ensure that the message is understood properly can do a lot to reduce anxiety in the workforce.Resources  https://www.ryerson.ca/accessibility/guides-resources/virtual-meetings/.  https://www.nad.org/videoconferencing-platforms-feature-matrix/.  https://medium.com/cmcnally/accessibility-strategies-for-deaf-hard-of-hearing-people-in-remote-meetings-e19781b3bc4.  https://disabilityin.org/resources2/covid-19-response-accessible-tools-and-content/.  https://www.toolbox.com/hr/hr-strategy/articles/has-remote-work-increased-disability-inclusion-in-workplace/.  https://angel.co/blog/how-remote-work-impacts-employees-with-disabilities.  https://www.forumone.com/ideas/an-accessibility-inclusion-checklist-for-virtual-events/.  https://equalentry.com/slack-vs-discord-which-is-better-for-screen-readers/.  https://www.access-board.gov/about/meetings.html.  https://knowbility.org/blog/2021/welcoming-accessible-virtual-meetings/.Checklist  Ensure you have captions enabled in Zoom, Google Meet or Microsoft Teams.  Make sure all slide presentations have captions for their images.  Evaluate any handouts to ensure that they are accessible.  Don't just send PDFs, where possible include  the original document as well.  If you know people attending have disabilities, ask them about what accommodations might be useful.Key questions  What is the most effective way to communicate at this time with those involved?  Are meetings organized before hand to allow people to prepare and fully participate?  How does the facilitator make room for people of all abilities to participate?  Have people with disabilities been asked if a minder would be beneficial?"
      
    },
  
    {
      
        "title"    : "Creating accessible documents",
        "url"      : "/playbook/documents",
        "content"  : "Content is often organized in stand alone documents. Whether using Google, Microsoft or OpenOffice formats, governments need to create and share text, presentations, or spreadsheets to share knowledge. There is increasing pressure to see that these are also accessible to people with disabilities.TemplatesTemplates are a good way to establish consistency within an organization. Investing time to ensrue that the templates used to are accessible helps to reduce the overall level of effort. A good template will be built with good color contrast, clear font styles and sizes.Microsoft: To add a template in Word, Excel or Powerpoint  Click on "Tools", then click "Templates and add-ins" from the dropdown menu.  Click on "attach" and add the MyTemplate.dotx.  Make sure to check "Automatically update document styles.  Add the new template by clicking the "+" button under the Global Templates and Add-ins section.This will adjust the Styles pane with the new template"s font styling.ThemeA theme can be created for the use of the colors based on your branding style guide.  Colors need to make sure its color ratio meets WCAG 2.1 AA.Microsoft: To add a theme to Word  Click on the "Design" Tab.  Click on the drop-down arrows beside "Themes".  Click on "Browse for Themes…" and add the MyTheme.thmx file.Microsoft: To add a theme to PowerPoint  Click on "View" from toolbar at top.  Select "Master" from drop-down menu, then select "Slide Master" .  Click on the "Slide Master" tab .  Click on "Themes" and select "Browse for Themes…" add the MyThemes.thmx file.Microsoft: To add a theme to Excel  Click on "Page Layout" tab.  Click on the drop down for "Themes" and select "Browse for Themes.." from the menu, and add the MyTheme.thmx file.TipsTip for Images  If images contain text, within Microsoft Office you can use SmartArt to avoid floating elements.  Elements need to be wrapped in-line with text.  All images should include an text alternative (alt text), a description of the image is the user cannot see the image.Add an alternative text to images/videos  Right click on the image you have added.  Select "Edit alt text" from the drop-down menu.  This will open a sidebar on the right of your screen, to add or edit the alt text of the image, or mark as decorative if image should not be read to a user with a screen reader.Tips for ContentAdd a document titleWhen converting a document to a web page, it should be given a descriptive and meaningful title.  Click on "File" in toolbar.  Select "Properties" from the drop-down menu.  Click on "Summary" tab and add a Title.Tips for Documents (i.e., Microsoft Word, Google Docs)  Use font sizes between 12 and 15 points for body text.  Create document title for when converting file to html.  Text should have a solid background color rather than a pattern.  Tables should be used for tabular information rather than for style formatting.  Using text boxes or shapes elements will require alt text and wrapped in line with text.  Use heading to structure content, rather than just bold text.  Add page numbers in footer bottom right.  Color should not be used as the only visual means of conveying information.Tips for Presentations (i.e., Microsoft PowerPoint, Google Slides)  Use font sizes between 12 and 18 points for body text.  Logical tab order, title should always be first.  Create document title for when converting file to html.  Use slide notes.  Set a logical tab order.  Text should have a solid background color rather than a pattern.  Tables should be used for tabular information rather than for style formatting.  Use heading to structure content, rather than just bold text.  Color should not be used as the only visual means of conveying information.Tips for Spreadsheets (i.e., Microsoft Excel, Google Sheets)  Make use of the cell styles rather than using the formatting tools on one cell.  Naming the different data ranges within your spreadsheet makes it easier to navigate through the document and find specific information.  Use charts to make data more understandable for some audiences.  Add title and labels to charts.  Add a document title if converting to HTML.  Use font sizes between 12 – 18.  Use normal weight rather than bolds or italics, or use bold over italic.  Color should not be used as the only visual means of conveying information.  Text should have a solid background color rather than a pattern.ResourcesFor publishing accessible electronic documents.  Why GOV.UK content should be published in HTML and not PDF (UK Government Digital Service)  Create Accessible Documents (U.S. General Services Administration)  Publishing accessible documents (UK Government Digital Service)  How to Create Accessible Documents (Toronto Metropolitan University)  Understanding Document Accessibility (Toronto Metropolitan University)  SCULPT - Shaping documents and content for everyday accessible and inclusive practice (Worcestershire County Council, UK)See also  Document Guide"
      
    },
  
    {
      
        "title"    : "Follow global initiatives",
        "url"      : "/playbook/follow-global-initiatives",
        "content"  : "The European Union is providing a lot of leadership for governments that prioritize accessibility. The Web Accessibility Directive forces member states to measure their accessibility barriers by: Identifying the barriers in existing Information Communications Technology (ICT) through automated accessibility monitoring, and creating feedback loops through accessibility statements. Commit to being transparent and accountable by regularly publishing results which allow constituents to see progress on our inclusion goals.They are also investing in prevention by participating in and leading initiatives that make implementing accessibility easier for everyone. The European Commission is investing in initiatives like the We4Authors Cluster which is making it easier for everyone to have more accessible sites. Bringing together a common Content Management System (CMS) and improving the authoring tools can have a huge impact.While we have yet to uniformly implement global accessibility standards, the European Commission strategy has started working more closely with the W3C's Web Accessibility Initiative (WAI) to implement best practices.A handful of organizations are sponsoring WAI projects. This public-facing work both contributes to the practice of open government, and ensures that the tools they develop can be maintained by a broader community.Checklist  Monitor the W3C's Web Accessibility Initiative for new policies, resources and tools.  Follow the UK's Government Digital Services actively blog about their work.  Check the latest WAI WCAG Recommendation to see what will give you the best guidance.Key questions  Is your organization able to sponsor the groups like the WAI which are building best practices?  Are there initiatives like WCAG 3.0 which are seeking input?  Are there organizations similar to yours which are doing inspiring work?"
      
    },
  
    {
      
        "title"    : "How to do manual testing",
        "url"      : "/playbook/manual-testing",
        "content"  : "A comprehensive accessibility testing plan must include manual testing. As automated testing generally only catches about 20-30% of accessibility errors, without manual testing the majority of issues are going to be missed.There are various types of manual testing that can be incorporated into your testing plan, some are easier than others to work in based on resources, expertise, available tools, etc. You can create your testing plan based on what works for you and your team; the most important thing is that some amount of manual testing is consistently part of the process.Keyboard testingKeyboard testing can catch a high volume of potential accessibility issues. Keyboard testing can identify if semantic elements were not used—which typically lead to larger issues with other devices. It can also identify if the reading order is incorrect and if there are keyboard traps on the page, among other issues.Keyboard testing is easy to do and requires no specific expertise or hardware—other than a keyboard—so this type of  testing can be shared among various project team members. It is one of the most important manual tests that should be included in any testing plan.To do keyboard testing:  Confirm that all interactive elements are available and actionable using the keyboard only.          Use TAB to move forward through the page and SHIFT + TAB to go backwards.      SPACE and ENTER are the most common keys to activate elements but for more custom elements WebAIM provides a good resource.        Confirm that while tabbing, all interactive elements have a visible focus indicator when receiving focus.          Typically, this is a colored border around the element.        Confirm that while tabbing, the order of tabbing moves logically through the page. It should follow a typical reading order - top to bottom, left to right.Zoom and resizingThe purpose of zoom testing is to confirm that at 200% there are no visual or functional issues from the page resizing. It is also important to specifically test text resizing, that it is working as expected.Zoom testing is another testing type that can be completed without any specialized hardware, software or expertise, making it relatively easy to add to a basic testing plan.To test content zoom:  Set your browser width to 1280 pixels.  Use CTRL + or CMD + to zoom in to 200%.  Confirm that:          You can see each element and all the text that you could previously      You can use and interact with each element (both with keyboard and mouse)      Confirm that horizontal scrolling is not present except for a few exceptions (i.e. data tables, images, charts, etc.)      To test text resizing:  Within your browser, update your settings to increase text size.          Chrome: Settings > Appearance > Font size      Firefox: Settings > Language & Appearance > Fonts      Edge: Settings > Appearance > Fonts        Confirm that all text on the page resizes appropriately based on the indicated browser size.Contrast and use of colorThe most basic rule in color contrast testing is to confirm that all elements have a contrast ratio of at least 4.5:1 against their background. There are some nuances with this requirement where a lower ratio can pass if necessary, however it is always best to aim higher whenever possible.Color use within a page or product should also be evaluated to ensure that it is not the only means of conveying information. This is especially helpful for folks using your product who may be colorblind or have low vision.While testing color does not require any specific testing tools, there are some available that are helpful and may make testing easier:  Contrast finder  WebAIM Contrast Checker  Colorblindly plugin for Chrome  Built-in browser rendering for color blindnessTo test color contrast:  Small text (20px or smaller) has at least a 4.5:1 contrast ratio  Large text (greater than 20px) has at least a 3:1 contrast ratio  Non-text elements have at least a 3:1 contrast ratio to their background and to neighboring elements. For example:          Graphics - sections in a pie chart must meet requirements      UI elements - colors indicating if a checkbox or radio button is selected must meet requirements      To test use of color:  Identify all links and confirm that each has an underline.  Identify any data elements (i.e. charts, tables, maps, etc.) and confirm that the information within each is presented with more than just color.          For example, in a table if yes is indicated by coloring a cell green, does it also use another indicator? A checkmark, a pattern, etc.?        Confirm that any instructions given do not refer to color. (e.g. Click the blue button)Next stepsWhen you are ready to learn more, here are some further guides and resources for accessibility testing:  Screen reader testing  Implement automated testing  Additional Tools"
      
    },
  
    {
      
        "title"    : "Avoid PDF documents",
        "url"      : "/playbook/pdf",
        "content"  : "Most PDFs simply do not meet the Section 508 requirements. It is just simply so easy to produce PDFs, but so difficult to produce accessible ones. There are very few tools that allow you to tell the difference between.The Luxembourg government has several open source accessibility projects inclucing their simplA11yPDFCrawler. This small government has created a great tool which collects and scans PDFs for known accessibility errors. VeraPDF or VeraPDF on GitHub is another open source option that can provide more detailed results but has a more complicated installation.It is possible to create PDF files that meet requirements of Section 508, but it is often overlooked or not done properly. Often the source documents used to create them do not have proper semantics. It is always more expensive to try to remediate a PDF than to implement accessibility best practices into the authoring tool.The UK's Government Digital Services model decreases the reliance on PDFs and is actively working to move away from them online and pushing for HTML content instead. When publishing a PDF is unavoidable, ideally an HTML or MSWord version of the content should be available as well.For creating accessible documents in Microsoft Word, Excel or Powerpoint, is the preferred method. Microsoft offers an Accessibilty Checker tool, although this may not be an extensive check of the document, it does show major accessibility issues needed to fix.Visit Creating Accessible Documents.Checklist  Check that the PDFs are accessible prior to allowing them to be posted to the website (ideally with a tool like the CommonLook PDF Validator).  Track source files, so that additional improvements can be made, if barriers are identified.  Encourage teams to build documents in HTML first.  Test PDFs with assistive technology.Key questions  Does the department have a clear public policy on use of PDFs?  What is the process to review that all PDF documents are accessible?  Are there better alternatives to using PDFs that could be used?  Is a print-friendly version useful for some users?"
      
    },
  
    {
      
        "title"    : "Support personalization",
        "url"      : "/playbook/personalization",
        "content"  : "Many users are not familiar with the power that they have to modify or control how they engage with or modify content to meet their needs. Users have always been able to adjust the font size by Pressing the "CTRL and +" and "CTRL and -" keys. Increasingly users are choosing to use dark mode, especially with their phone. Users can also control animation by choosing reduced animation in the operating system.There are widgets that allow users to modify the spacing, font, focusable elements, and even generate a table of contents for your content. There are browser extensions that can force dark mode, eliminate pieces of your page, or read it aloud to you. We are seeing a real explosion of how people of all abilities are engaging with your site, even eye tracking usage is increasing.The BBC had pioneered this with My Web My Way (MWMW), but this has since been archived. UK's AbilityNet has taken this on and produced My Computer My Way (MCMW), modernizing much of the same content. The BBC now simply maintains an impressive list of accessibility information on their main accessibility page including links to Microsoft, Apple and Google.It is worth adding links to something like MCMW into accessibility statements to help educate users about how to get more power over their devices. Most people do not have anyone help them learn how to make best use of the new technology that is coming built-in with new operating systems. Front-end developers  should also be checking that their sites work with a broader range of users settings.The Inclusive Design Research Centre's Preferences Framework Editor provides a good example of how many user preferences can be exposed through the user interface. Not only can users choose from a variety of font sizes and color options, but they can also choose between multiple fonts, adjust the spacing, and expose a table of contents from the page's heading structure.Checklist  Test that your site respects the following CSS media queries:          Dark mode (prefers-color-scheme).      Reduced motion (prefers-reduced-motion).      Reduced data (prefers-reduced-data) - Coming soon!        Test with reader mode in Firefox and Edge?  Listen to your content being read to you and see if it could be improved.  Find ways to incorporate tools into the design and development phases to make personalization easier for everyone (ie. ability to toggle color modes and font sizes).Key questions  How much responsibility do you want to have in educating your users?  How do you integrate this into your testing so it can be maintained?  How do you design your brand so that it can be conveyed even when the user is able to override how basic elements of your site are being displayed?  Are we putting the burden of technology on the user?"
      
    },
  
    {
      
        "title"    : "Build a community of practice",
        "url"      : "/playbook/practice",
        "content"  : "Within and across government departments, people with related knowledge and responsibilities are often scattered. Without a deliberate effort to build a shared understanding and define how digital accessibility is done, the approach and expertise can vary widely. Establishing a community of practice can make it easier to share knowledge and best practices, and help your organization align behind common goals for digital accessibility.Digital accessibility requires technical knowledge, but also personal empathy. Understanding how others experience the digital world is critical for addressing their needs. Therefore, it's crucial that a community of practice on accessibility involves people with disabilities.As a whole, government bodies need to get better at identifying accessibility barriers, removing them from their systems, and preventing new ones from occurring. This will take a real community effort, and current approaches have not been up to the task. Building a community of people who are working together to identify, resolve and prevent errors will make your organization's accessibility goals more achievable and sustainable.The BBC is a real leader in this space, building out a Champions Network. Not everyone can be an accessibility expert, but we can have more people who care enough about it to become champions. Ability net has a great resource on how to build and grow your accessibility champions network.Checklist  Start a newsletter or slack channel to start a conversation about accessibility.  Work to collect best practices implemented by internal teams.  Get management buy-in for a champions network.Key questions  How can staff reach out to learn from their peers when they run into an issue where there isn't a simple solution?  What can be done to include people with disabilities from within the organization?  What can be done to build good accessibility and inclusion practices into our teams?"
      
    },
  
    {
      
        "title"    : "Include people with disabilities",
        "url"      : "/playbook/pwd",
        "content"  : "OverviewActually engaging with people with disabilities (PwD) is key. Their lived experience is critical for identifying issues that a test and someone without disabilities may not catch. This can be accomplished by assuring user research in discovery stages includes PwD. Usability testing of specific site features should also include PwD to ensure that the solution works as expected.Out of respect for their time, PwD shouldn't be engaged to test the accessibility of a website until the results of automated and basic manual tests are implemented.PwD's lived experience is critical for catching issues and errors that the tests miss, but it is important to not waste people's time replicating known problems that a computer or a non-disabled person can easily identify. See the playbooks on automated testing and manual testing for more information.When recruiting a testing cohort, it is important to consider the range of disabilities that need to be addressed. Should you test with people who were blind from birth and who use Braille, or those who became blind and use an audio interface? A legally blind person may have some sight, and may use a screen reader in combination with a screen magnifier. If there are audio components, it may be important to include members of the deaf community. People have a range of experiences of perceiving colour, and this can change over time. These are just a few examples.There are many different disabilities and people experiencing combinations of them. Depending on the size of the project you may want to adjust the number of participants who are involved. Most projects simply do not include enough people with disabilities. Remember too that there is variation in how people use Assistive Technology, and so one perspective may not reflect the needs of the whole community. A minimum size would include people with limitations in sight, hearing, mobility and cognition.Many disabilities are invisible, and because of the stigma that can be associated with disability, people may not feel comfortable disclosing this information to their peers. It is statistically likely that a team already includes people with disabilities, but often this is hidden and unknown to the rest of the group.Robust products and services are co-designed with the users. People with disabilities have expertise through lived experience that needs to be recognized, especially when building tools and services for them. "Nothing About Us Without Us!" is a common call in the disability movement, because all too often, people with disabilities are not engaged. Inclusive design is a process which is open and transparent and actively engages a wide diversity of abilities.Checklist  Include people with disabilities early in the process and before a product/service is launched  Build in the costs of accessibility testing into the project budgetKey questions  Are you building to the Pareto Principle, or the fringe?  How are you including a range of disabilities into your consultation process?Related  Do Manual Testing  Test with Assistive Technology"
      
    },
  
    {
      
        "title"    : "Provide role based evaluations",
        "url"      : "/playbook/roles",
        "content"  : "Creation of modern digital content involves a great many distinct roles. There have been multiple efforts to organize the different roles that occur with each digital team.  USDS's Accessibility for Teams  UK's Department for Work & Pensions' Accessibility Manual (DWP) - Guidance for your job role  Gov.UK Service Manual - What each role does in a service team  Australia Broadcasting Corporation - Accessibility Tips for Teams (PDF)  NZ Government - Web Accessibility Guidance project  International Association of Accessibility Professionals (IAAP) - Mapping WCAG2 to Project Roles and Model ICT Accessibility Policy Report  Deque Labs - Defining Actionable Metrics  PEAT Works - Accessibility Staff Training for Specific RolesWe've taken these lists, added other roles that we didn't see included and included them here. With each role we are including tools that we think would be most useful for that role. Where appropriate we have also included links to the W3C's Accessibility Responsibility Breakdown for WCAG 2.0 requirements.Accessibility Lead  The lead is responsible for providing an overview of the whole project and ensuring that the components flow together for the user.  Tools: Purple Hats, MSU's Domain Accessibility Audit or Siteimprove, The Book on Accessibility and Accessibility Insights. Deque defines the Defining Actionable Metrics for the central accessibility function. The UK has provided a great description the accessibility specialist role.Audio and Video Media (AV)  W3C - Making Audio and Video Media Accessible  Section 508 - Create Accessible Synchronized Media Content  Mozilla - Accessible multimedia  AMI - YouTube Accessibility  Sitepoint - 8 Steps to Creating Accessible Video  Washington.edu - Creating Accessible Videos  IU.edu - Make video and audio accessibleBack-end Engineer / Developer  W3C Accessibility Responsibility: Back-end Development.  Tools: axe and Accessibility Insights.  Training: Section 508.gov recommendations & University of Minnesota guide.  Resources:          Free Book: Web Accessibility for Developers.      A11ycle's Back-End Developer      Business Analyst  See: UK DWP: Business Analyst, BBC: Accessibility, News and Business Analysts  and UK Service Manual  "As a Business Analyst in an agile team, you're involved in the critical parts where accessibility is often overlooked. Your role is often a facilitating role, to make sure user stories and conversations always include accessibility."  "Business Analyst maps to IAAP's Analysis, Architecture, Content Strategy, and Interaction Design and Usability." - A11ycle.com  Write the accessibility acceptance criteria (design review, documentation, high risk factors, scenarios, and awareness).  W3C Accessibility Responsibility: Analysis.  Tools: WebAim's WAVE Toolbar.Content Author / Writer  See: USA: Accessibility for content designers  W3C WAI - ARRM Project: Accessibility Roles and Responsibilities Mapping.  Tools: Sa11y, Editoria11y, retextjs and HemingwayApp  Checklist:          Does the content meet your readability target?      Are there any unusual words to watch for?      Do images have meaningful alternative text that is related to the other content?      Are there large blocks of text, or is it broken up by appropriate headers?      Can links be understood without any surrounding content?      Have you stated major point(s) first before going into details?      Limit each paragraph to one idea and keep it short.      Use everyday words. If you must use technical terms and acronyms, do you explain them on the first reference?      Can you omit unneeded words?      Do you use headings, lists, and simple tables to make reading easier?      Did you have someone review your work?      Is it easy to scan and pick out the main points? Are headings clear and descriptive?      Are you using inclusive language?        Resources: CivicAction's Plain Language Guide, W3C -  Writing for Web Accessibility, Blog post for content authors, Content Design London - Readability Guidelines, Singapore Government Design System - Accessibility for Content, USA OPM Information Management, Canada: Writing principles for web content and plainlanguage.gov.Content Designer / Information Architecture  See: UK DWP: Content Designer, UK Service Manual and NZ Government  "Making the content as easy to understand as possible makes it better for everybody. There are common scenarios where people might benefit from simple content. For example, people where English is not their first language or people who have Dyslexia."  "Reviewing content to make sure it's accurate, relevant, accessible and written in line with" style guide.  W3C Accessibility Responsibility: Architecture.  Tools: WebAim's WAVE Toolbar.  Resource: CivicAction's Plain Language Guide, Blog post: Accessibility: Guidelines for Information Architecture, UX Design, and Visual Design, USA Plain Language Community of Practice and UK GDS Content design: planning, writing and managing content.Customer Experience / Service Design / Content Strategy  W3C Accessibility Responsibility: Content Strategy.  Tools: WebAim's WAVE Toolbar.  Resources: Accessibility and the Digital Service Standard, Accessible service design.Delivery Manager  See: UK DWP: Delivery Manager and UK Service Manual  "As a Delivery Manager you need to make sure that accessibility is considered when sizing up stories and that very feature is fully accessible before it is released."  "Making sure accessibility is factored into each feature or activity the team's working on"  Tools: WebAim's WAVE Toolbar.DevOps  See: UK Service Manual  Tools: pa11y, cypress-axe and Accessibility Insights.  Resources: Blog - Embedding Accessibility into the DevOps Process.Digital Performance Analyst / Data Analysts / Business Intelligence  See: UK DWP: Digital Performance Analyst and UK Service Manual  "As a Digital Performance Analyst, most of your considerations will be around presenting statistical data so that they don't exclude anybody that might not be able to perceive complex charts or tables of data."  Tools: WebAim's WAVE Toolbar.Executives  See: Section508.gov's Executive Guide to Federal IT Accessibility and NZ GovermentFront End Engineer / Software Engineer  See: USA: Accessibility for front-end developers, BBC: Accessibility, News and Developers, UK Service Manual and NZ Government  "As a Software Engineer or Frontend Developer, you have one of the most important roles when it comes to accessibility. A design can have considered accessibility, but it's up to you to build it to work correctly. By using existing libraries and frameworks such as GOV.UK Frontend and DWP CASA, you can get a lot of good practices for accessibility built in, however we need to be mindful of how we apply them."  "Build accessible software with a focus on what users need from your service and how they'll use it."  "Front-End Developer maps to IAAP's HTML and CSS Prototyping and Front-End Development." - A11ycle.com  W3C WAI - ARRM Project: Front-End Developer Responsibilities Mapping.  Development W3C Accessibility Responsibility: Front End.  Tools: Accessibility Insights and axe DevTools.  Checklist          Run the FastPass's automated axe checks on every page.      Check that the Tab stops follow a logical order when navigating with a keyboard.      Look over the elements that are marked Needs reviews to see if there are elements where a manual review can identify whether it is an issue or not.      On new patterns make sure to complete the rest of the assessment to ensure that the new functionality meets WCAG requirements.      See more from BBC's Checklists.        Resources          Building Accessible Front-Ends      Accessibility Tips for Frontend Developers      W3C WAI's Developer Modules Curriculum      Helping developers write accessible code      A11ycle's Front-End Developer      W3C - Developing for Web Accessibility      Singapore Government Design System - Accessibility in Code      The Book on Accessibility      HTML & CSS Prototyping  HTML & CSS Prototyping W3C Accessibility Responsibility.Interaction Designer  See: UK DWP: Interaction Designer and UK Service Manual  For more see UX.Product Manager / Project Manager  See: USA: Accessibility for product managers, UK DWP: Product Manager, BBC: Product Owner, BBC: Project Manager and NZ Government  "Make sure the team know their responsibilities"  W3C Accessibility Responsibility: Project Manager.  Tools: Site-wide scanners and WebAim's WAVE Toolbar.  Checklist          Verify that personas include permanent, temporary or situational examples for vision, mobility, hearing, and cognitive disabilities.      Ensure that accessibility is being considered with every sprint (or alternative process).      Find ways to prioritize common, weird and critical barriers that are discovered in QA.      Prioritise user stories for each work sprint and look for ways to include permanent, temporary & situational disabilities.      Identify where to include people with disabilities in the process.      Ensure you are tracking Actionable Metrics        Resources: BBC's Product Owner Checklists & BBC's Project Managers Checklist, Planning and Managing Web Accessibility, Managing for Accessibility, Section508.gov's Accessibility Playbook, Disability Fundamentals Training for Managers, The Book on Accessibility and Accessibility for Product Managers.Procurement Manager  Tools: WebAim's WAVE Toolbar.  Resources: DisabilityIN - Accessible Technology Procurement Toolkit.Quality Assurance / Quality Control Tester  See: UK DWP: QA Tester, BBC: Accessibility, News and Testers, UK Service Manual and NZ Government  "As QA Tester, you're responsible for checking if the finished product is actually accessible. This means running automated tests, manually checking the pages against the WCAG criteria, and testing usability with assistive technology."  W3C Accessibility Responsibility: Quality Control.  Tools: Purple Hats, MSU's Domain Accessibility Audit or Siteimprove, Pa11y and Accessibility Insights.  Resources:          BBC's Checklist, Paul Adams Checklist.      A11ycle's Quality Assurance      Search Engine Optimization  W3C Accessibility Responsibility: SEO.User Researcher  See: UK DWP: User Researcher, UK Service Manual and NZ Government  "As a user researcher, you will help the team to understand the needs of the people who use the service, including those users who might have impairments and use assistive technologies."  Tools: WebAim's WAVE Toolbar  Resources: UK GDS Blogs, How inclusive user research makes your products better, Working with Others: Accessibility and User Research, A Comprehensive Guide to Accessible User Research, What user researchers need to know about accessibility, How to Conduct Usability Studies for Accessibility, Conducting Accessibility User Research: What's Really Needed?, The Book on Accessibility and Tips For Conducting Usability Studies With Participants With Disabilities — Smashing Magazine.UX  See: USA: Accessibility for user experience (UX) designers  "As an Interaction Designer, you play an important part of making sure a service or website is accessible. Making screens and interactions simple makes things easier for everybody. Overcomplicated designs or using inaccessible design patterns can have a knock-on effect when it's time for developers to code up your designs."  "User Experience maps to  IAAP's Content Strategy, Interaction Design and Usability, and to a lesser extent HTML and CSS Prototyping." - A11ycle.com  W3C WAI - Accessibility Responsibility: Usability and ARRM Project: UX Designer Responsibilities Mapping.  Tools: WebAim's WAVE Toolbar.  Also see Interaction Designer.  Checklist:          Make sure that the tab order is meaningful and that focus is considered in the design process.      Ensure that ARIA Landmarks are identified for each of the pieces of content used in the site.      Look to see that both the forms and errors associated with those forms are understandable.      Ensure that decorative images are clearly identified so that they are not described.      Check to see that the touch targets exceed 44 px or 10 mm.        Resources: Accessibility guidelines for UX Designers, W3C Accessibility, Usability, and Inclusion, and Deque blogs Accessible User Experience & Design, The Book on Accessibility, Stephanie Walter's Resources and Accessibility for UX and UI Designers.Visual Design / Graphic Design  See: USA: Accessibility for visual designers, UK Service Manual and NZ Government  "Everyone benefits from designs that are easier to see. People with different visual abilities see your designs in varying ways—the diverse nature of impairments creates a wide variation in how your designs are perceived. A clean and clear visual presentation helps everyone make sense of a website's information and functionality."  W3C WAI - Accessibility Responsibility: Graphic Design and ARRM Project: Visual Designer Responsibilities Mapping.  Tools: Open source color contrast tools and DigitalA11y's Accessibility Tools and Resources for Designers  Checklist:          Is there enough contrast between text and its background color?      Are buttons and links semantically defined?      Can you quickly understand the meaning of the page and complete your task?      Can you easily read and comprehend textual information on the page?      Can you easily understand content associated with graphics, icons, and images?      Can you understand the overall trend of the graph? Can you quickly grasp the relationship between parts of the data?      Can you understand key information and perform critical tasks on a mobile device?      Can you reach everything that's interactive using the tab key?      See more from BBC's Checklists including information about an accessibility design review.        Resources:          W3C -  Designing for Web Accessibility      Stop Designing For Only 85% Of Users: Nailing Accessibility In Design      Designing For Accessibility And Inclusion      BBC - How to design for accessibility      Geri Reid's WCAG for designers      Singapore Government Design System - Accessibility in Design      A Designer's Guide to Documenting Accessibility & User Interactions by Stéphanie Walter      We plan to continue to add to this as other role specific advice becomes relevant. The W3C's ARRM Project - Accessibility Roles and Responsibilities Mapping will be mapping this out in more detail in the years to come.Checklist  Identify list of digital roles in your organizations.  List what each role can do to enhance accessibility.  Provide checklists personalized for each role.  Look for educational materials that are focused on each role.Key questions  What digital content creation roles does your organization have?  Where are there opportunities for barriers to be introduced in your digital content?"
      
    },
  
    {
      
        "title"    : "Accessibility statements",
        "url"      : "/playbook/statements",
        "content"  : "A complete, well rounded accessibility strategy should include an accessibility statement. But what exactly is an accessibility statement? How do you write one and what type of information should be included?What is an accessibility statement?An accessibility statement is a public declaration that highlights the commitment of a company or organization to accessibility and inclusion.Accessibility statements are intended to provide site visitors with information about the accessibility of the website. This information can help people use and navigate the site by setting expectations around site standards and providing details about potential known barriers or technical compatibility.The CivicActions accessibility statement can be found in the footer of our main website.Why provide an accessibility statement?In some cases there is a legal requirement, which is a very compelling reason to have one. For example, all US Federal agencies must maintain an accessibility statement with certain information as defined by the Office of Management and Budget (OMB) memorandum from December 2023.However, even if there isn't a legally mandated requirement, providing an accessibility statement on your website shows site visitors that you value accessibility as a  social responsibility and that providing access to information is a priority for your organization.Writing an accessibility statementAt a minimum, the following information should be included in your statement:  A commitment to accessibility  The Web Content Accessibility Guidelines (WCAG) standard that the website or product adheres to (e.g. WCAG 2.1 AA)  Any known limitations or existing issues that site visitors should be aware of to help to prevent frustration for the user  Contact information for what to do if/when a user encounters a barrier or issueThe following additional information would also be good to include:  Technical specifications, such as which browser/devices work well and which may have known compatibility issues  Remediation plans for any known or existing accessibility issues  Any links or references to applicable laws and policies  Date the statement was last updatedBased on your particular website/product, there may be additional minimum requirements or some of the additional information mentioned above may be mandatory. For example, US Federal agencies must include (among other things) the date the statement was last updated and also a specific feedback mechanism for reporting issues to the appropriate 508 program office. When drafting your own accessibility statement, it is important to research specific requirements for your region and sector that may impact the information that should be provided.Also, remember that an accessibility statement is for site users, so it is important to write for that audience. Use plain language when writing your statement to allow users to easily understand the information you are telling them.Resources  W3C- Developing an Accessibility Statement  Section508.gov - Developing an Accessibility Statement  Model accessibility statement from GOV.UK"
      
    },
  
    {
      
        "title"    : "Invest in accessibility training",
        "url"      : "/playbook/training",
        "content"  : "Many government staff have not received adequate (or any) accessibility-specific training. Even as there are many resources available there is generally a lack of awareness—but when people find these resources they are often quick to take advantage. For example, when the UK's Government Digital Services (GDS) offered a free course on content design through Future Learn, over 10 thousand people signed up.Some of our favorite, free accessibility courses include:  Web Accessibility by Google;  Digital Accessibility Foundations by the W3C;  Information and Communication Technology (ICT) Accessibility by GeorgiaTech;  Assistive technologies and online learning by the Open University.Podcasts are another great way to learn about web accessibility—including A11yRules.com and Human Potential At Work. While these resources are often available for free, the publishers usually depend on donations to support the ongoing education work. If you choose to listen, please consider contributing to a Patreon campaign to support their wonderful work. Supporting these initiatives is a cost-effective way to increase the availability of new accessibility resources.There are also several high-quality accessibility guides available for free. For example, the US government has produced a guide with 18F. Rather than creating a new guide from scratch, these resources are available to build upon and improve. CivicActions is looking to extend these to provide an accessibility playbook for people interested in accessibility best practices.Public sector employees must be encouraged to take advantage of these resources to best serve their constituents. Accessibility best practices change quickly, so it is important to invest in a sustainable accessibility training program. The Section508.gov's Technology Accessibility Playbook includes a play on educating the workforce.Checklist  Schedule time to participate in Global Accessibility Awareness Day and International Day of People With Disabilities (Dec 3rd).  Follow more accessibility people/organizations on Social Media.  Read and share books on accessibility best practices.  Subscribe to free accessibility videos & podcasts.  Ensure key staff are regularly taking new training courses like Web.dev's Learn Accessibility.Key questions  What are you doing to help keep up-to-date with the latest best practices?  Where can we learn from adjacent disciplines to learn how to improve accessibility of the product/services that you work with.  Are there new assistive technologies that are worth learning about?  How are new people in the organization brought in and educated about accessibility?"
      
    },
  
  
    {
      
        "title"    : "CivicActions' Accessibility Champions Program",
        "url"      : "/guide/champions-program",
        "content"  : "Building an accessible culture through our Champions ProgramThe CivicActions Accessibility Pledge confirms our commitment to delivering inclusive digital services. We don't take this pledge lightly. We know it takes a lot of buy-in and dedication to build a culture of accessibility. It's not something that a few accessibility experts sprinkled throughout the company can deliver on alone. It takes company-wide effort. The Accessibility Champions program was created to offer CivicActioners a path for increasing leadership and confidence in furthering accessibility initiatives across projects and roles. This community of Accessibility Champions (ACs) are integral to creating and spreading an accessible culture throughout CivicActions.Champions are responsible for fostering awareness and action on digital accessibility within their teams. ACs are a conduit of information from the Accessibility Practice Area to their functional and/or client teams. They also bring concerns, findings, and practices from their functional and/or client teams to the Accessibility Practice Area to share knowledge across teams. Our Champions support their team(s) in building accessibility confidence and by advocating for continual improvement.Objectives of the Accessibility Champions ProgramWe are building a program in which:  Everyone at CivicActions understands the importance of digital accessibility and receives basic training  Teams are equipped to improve the accessibility of the products they build  CivicActions staff are able to improve their skills, knowledge, and leadership in furthering accessible technology  We share what we learn with the wider communityProgram recruitmentAll CivicActioners are encouraged to become Accessibility Champions. Champions come in all sizes and shapes and it is expected that there will be differences in the needs that functional and client teams have. We have ACs on client teams and in functional teams (other practice areas). Teams may decide that they need to have people with more or less experience to lead. Some teams will have only one, but some may have more Champions, particularly if there is mentoring or a distribution of labor involved.Who makes a good Champion?Generally individuals volunteer for this role because they are interested in expanding their accessibility skillset and are passionate about leveling up the accessibility practices of their team. People who are motivating to others, self-directed, self-aware, in tune with team needs, and who have a bias toward action tend to make great Accessibility Champions.Champions typically have interest in…  Learning more about digital accessibility  Research and investigation  Ability to describe barriers in a way that allows them to be reproduced  Coaching and mentoring  Complex problem solving  Presenting to audiences  Relationship building  Conflict resolution  Understanding the systems that create barriers to participation  Learning to use and interpret the results of automated toolsBenefits of becoming a ChampionThe Champions program makes it easier to:  Increase your organizational impact: Many joined CivicActions because they wanted to work for an impact-driven organization. Helping make websites more accessible can have an impact on millions of people.  Advance your career: We also want to support people in their growth within the company. "Accessibility Champion" looks good on your resume. It will help CivicActions become better innovators and win work.  Build cross-functional relationships: The work of accessibility is multidisciplinary and brings you into contact with specialists, leaders, and stakeholders from areas you may not otherwise interact with. These connections improve team communication and can have a lasting impact on your career and exposure to related expertise.Expectations for ChampionsChampions are not expected to be accessibility experts, but they are expected to grow their accessibility knowledge and to support their teams in maturing accessibility practices. Having all of the answers is not required, but a willingness to find answers, foster communication between their client or functional team and the Accessibility Practice Area, and advocate for improved processes and practices is essential.A champion will…  Take responsibility for iteratively making the client's project more accessible  Recommend process, tooling or other changes to make accessibility a bigger part of the client team's growth  Work with the Accessibility Practice Area group to surface and codify best practices to share across the company  Surface opportunities for learning and process improvement  Help their functional role have a clear understanding of accessibility expectations for that role  Support team members in meeting accessibility goals including onboarding new membersSpecific examples include:  Raising accessibility issues in team meetings  Auditing projects for areas for improvement  Ensuring there is axe-core testing in our CI/CD process (pa11y with axe, Cypress-axe)  Ensure developers are using an accessibility linter (VSCode, phpStorm, atom)  Ensuring designers include accessibility annotations in wireframes  Working with the project team/PMs to better integrate accessibility into ticketing process  Coordinating actions using shared decision-making and prioritization criteria  Building checklists or default acceptance criteria  Do accessibility code reviews and help coach others on the team  Leading ARRM workshops if useful for new project or addressing backlogsChampion levelsThere is an infinite amount that can be done on accessibility. And yet, we want the program to be a welcoming place for the accessibility-curious to be able to join without the need for advanced study or certifications. Levels provide an on-ramp for staff that may be less experienced with digital accessibility as well as leadership and mentorship opportunities for more experienced staff. The levels are set up to encourage people to push themselves to learn more with time and practice.As champions gain skills, experience, and responsibility they can advance through three levels:Level 1 — Basic knowledgeNo previous accessibility knowledge or experience is necessary for this level, only an enthusiasm to learn. In addition to Accessibility Onboarding for new employees, all CivicActions employees are encouraged to take an Introduction to Web Accessibility course. All employees are welcome to attend the practice area calls and engage in the Slack channel to keep up with best practices and internal accessibility discussions. At this level, the goal is to be able to articulate the importance of accessibility and to identify and prioritize common accessibility issues.Level 2 — ExperiencedThis level is for employees who are able to analyze the accessibility of a task across multiple pages and components and recommend solutions with confidence. Open to employees who have worked toward more in-depth accessibility certification through International Association of Accessibility Professionals (IAAP) Certified Professional in Accessibility Core Competencies (CPACC), IAAP Web Accessibility Specialist (WAS) or DHS Trusted Tester. Level 2 Champions contribute to the website, write articles, and lead Accessibility Onboarding Workshops for new employees.Level 3 — Taking leadershipLevel 3 is all about impact. At this level, Champions are able to evaluate the accessibility of a product systemically and prioritize approaches which will have the biggest impact. On projects they are expected to track down and advance issues and assist teammates in navigating complex solutions. Internally responsible for the innovation of our Accessibility Practice Area. Level 3 Champions contribute beyond CivicActions by maintaining modules or themes, contributing back to open source, engagement with the W3C Working Groups, and by coaching clients and partners.Resources to start an Accessibility Champions programArticles and talks about beginning and growing Accessibility Champion programs to get you started.  Minnesota State Government: Accessibility Challenge - Nurture More Champions Part 1 & Part 2  LinkedIN's Program  The A11y Global Collective: Scaling Accessibility — Intuit's Accessibility Champions Program (YouTube)  AbilityNet          14 tips to build an accessibility champions' network      Creating an accessibility champions network (YouTube)        Aimée Danger          Accessibility Champions Program      Accessibility Champions Program + Empathy Lab (PDF)        GDS/BBC Webinar: Accessibility Culture eats WCAG compliance for breakfast  Sagar Barbhaya - Expand Your Outreach with an Accessibility Champions Program"
      
    },
  
    {
      
        "title"    : "Accessibility bug classification",
        "url"      : "/guide/defect-priority",
        "content"  : "CivicActions teams use this guidance to prioritize accessibility issues based on the degree of content interference caused by a WCAG success criterion failure. We treat accessibility issues as bugs, and have adapted priority definitions from Deque's issue impact classification.Note that:  The list is illustrative, not exhaustive, and  A failure can belong to more than one level depending on how severely it impacts content access.Teams may evaluate an issue further with respect to its impact on specific content, functionality, or usability. Reasons for adjustment should be included in the ticket description, and when new patterns or examples are identified they should be considered for inclusion in the table.            Access failure      Issue priority      Action                  Page-level interference (Single A criteria)                  no audio control (1.4.2)          keyboard trap (2.1.2)          no pause, stop, hide (2.2.2)          four flashes or above threshold (2.3.1)                    Highest user impact                  Dire, resolve immediately          Forces user to abandon essential workflow          Users with disabilities fundamentally blocked          Creates immediate organizational risk          Everything else can wait for this                    Do now        Bypass release cycle                    Primary component failure                  images missing alt attributes (1.1.1)          audio lacks captions (1.2.2)          video lacks audio descriptions (1.2.5)          content meaning wrong without CSS (1.3.2 F1)          text less than 4.5:1 contrast ratio (1.4.3)          an interaction is not keyboard navigable (2.1.1)          keyboard trap in one direction only (2.1.2)          user not warned of timeout (2.2.6)          form inputs missing a label (3.3.2)                    High user impact                  Significantly degrades essential workflow          Users with disabilities substantially blocked          Significant frustration for AT users          The issue has been around a long time          Other work can wait for this                    Do next        Address in next release                    Component interference                  headings missing/out of order (1.3.1)          content/component not in a landmark (1.3.6)          table is not well-formed (1.3.2)          content sequence wrong without CSS (1.3.2 F1)          skip to content link missing or broken (2.4.1)          tab order is non-sequential (2.4.3)          table is missing headings (2.4.6)          keyboard focus disappears/not visible (2.4.7)          instructions not with inputs (3.3.2 ARIA17)          form label missing but inferrable (3.3.2 G167)          custom control lacks full API support (4.1.2)                    Medium user impact                  Degrades non-critical workflows for AT users          Users with disabilities are slowed down          Some frustration for AT users is likely          Acceptable short-term workaround exists          Low priority issue that has been around a while                    Do soon        Address this quarter                    Page or component degradation                  iframe is missing title attribute (2.4.1 H64)          page titles duped/lack adequate detail (2.4.2)          link text lacks adequate context (2.4.9)          language not set at page level (3.1.1)          inconsistent labeling of same function (3.2.4)                    Low user impact                  Does not substantially degrade a workflow          Has a simple workaround          Hinders compliance          Annoyance bug          If the affected component is not actively used                    Do later        Address when doing related work                    Missing best practices      Lowest user impact                  No significant user value to fix          Only in unsupported browser or component                    Do as time allows      "
      
    },
  
    {
      
        "title"    : "Design systems",
        "url"      : "/guide/design",
        "content"  : "Government open design systemsWorldwide, government website design is being led by open source initiatives.USA  U.S. Web Design System (USWDS) — USWDS on GitHub  USA CMS Design System — CMS on GitHub  VA.gov Design System — VA on GitHub  California Design System — CDS on GitHub (uses Web Components)Europe and the UK  GOV.UK – Design System — GOV.UK Design System on GitHub  UK's Department for Work and Pensions Design System on GitHub  Iceland's design system mono repository  Portugal's Ágora Design SystemCanada  Canada – Web Experience Toolkit (WET) — WET on GitHub  Canada – Aurora Design System — Aurora on GitHub  British Columbia Government - Design SystemAustralia, NZ and Pacific  Australia – Design System (Archive.org) — Design System Components on GitHub  Australia's Health Design System — Health on GitHub  NZ – Design System — govtnz-design-system on GitHub  Singapore Government Design System — SGDS on GitHubMunicipal  City of Helsinki Design System  The New York Public Library's Design System — NYPL on GitHubOther open design systems  Okta's Odyssey Design System  IBM's Carbon open source design system — Carbon on GitHub Carbon's Accessibility (uses Web Components)  Impact Design System — Impact Desigh System on GitHub  VMWare's Clarity Design System — Clarity on GitHub Clarity's Accessibility (uses Web Components)  Emulsify — Emulsify on GitHub Emulsify's Accessibility  ING's Lion Design System — Lion on GitHub Lion's Accessibility (uses Web Components)  Talend's Coral Design System — Coral on GitHub (uses React Components)  Orange Digital Accessibility — Orange a11y-guidelines on GitHub  Google's Material Design — Material on GitHub Material's Accessibility (uses Web Components)  Adobe's Spectrum — Spectrum's Inclusive Design (uses Web Components)  Microsoft's Fluent Fluent UI on GitHub  Bridge Lab's Bold — Bold on GitHub Bold's Accessibility  Shopify's Polaris — Polaris on GitHub Polaris' Accessibility  Intuit's Design-systems-cli — Intuit on GitHub Quickbooks' Accessibility  Spark Design System — Spark on GitHub Spark's Accessibility  Redhat's Patternfly — Patternfly on GitHub  SAP's UI5 — UI5 on GitHub (uses Web Components)  Phase2's Outline — Outline on GitHub (uses Web Components)  Washington Post's Design System (UiKit)  GitHub's Primer — Primer on GitHub  Jstor's Pharos — Pharos on GitHub"
      
    },
  
    {
      
        "title"    : "Documents",
        "url"      : "/guide/documents",
        "content"  : "For Microsoft Word/Powerpoint, portable document formats and electronic publication documents.Government recommendations  Section508.gov: Create Accessible Documents (U.S. General Services Administration)  DigitalVA: Accessibility Guide  Why GOV.UK content should be published in HTML and not PDF (UK Government Digital Service)  Gov.uk: Publishing accessible documents (UK Government Digital Service)  Canada.ca: Digital Accessibility Toolkit  Worcestershire County Council: SCULPT for AccessibilityOther  Toronto Metropolitan University: How to Create Accessible Documents and Understanding Document Accessibility  Toronto Metropolitan University: Understanding Document Accessibility (Free E-book)  AbilityNet: Creating Accessible Documents (UK's AbilityNet)See also  Document Playbook"
      
    },
  
    {
      
        "title"    : "Events",
        "url"      : "/guide/events",
        "content"  : "  Blue Beanie Day  Global Accessibility Awareness Day  International Day of Persons with Disabilities  General calendar: Disability:IN"
      
    },
  
    {
      
        "title"    : "Glossary",
        "url"      : "/guide/glossary",
        "content"  : "Common accessibility terms.AccessibilityThe measure of a web page's usability by persons with one or more disabilities.Alternative textShort text primarily used by screen-reading software to describe images — usually 125 characters or less. Also known as alt text.Assistive technologiesTechnology designed so people with disabilities have greater functional capabilities with computer-based systems. This could be software or hardware and often benefits a broader range of computer users.Americans with Disabilities Act of 1990 (ADA)A United States civil rights law that prohibits discrimination based on disability.Audio browsersWeb browsers that provide a text-to-speech capability for the blind and visually impaired.Authoring Tool Accessibility Guidelines (ATAG) 2.0A WAI Guide to support authoring interfaces for both ensuring that people with disabilities can use them, and that they support authors in producing more accessible content.BarrierIncludes anything physical, architectural, technological or attitudinal, anything that is based on information or communications or anything that is the result of a policy or a practice that hinders the full and equal participation in society of persons with an impairment, including a physical, mental, intellectual, cognitive, learning, communication or sensory impairment or a functional limitation.Braille terminalMachines that convert text on a screen to braille by raising bumps through holes on a flat surface.CaptioningThe art of adding captions to a television program or movie.CaptionsA textual representation of sound. This is usually associated with videos, to display real time textual equivalent of speech. Sometimes this moves beyond speech to include other sounds relevant to the video.Content (vs. presentation)The separation of concerns design principle as applied to the authoring and presentation of content. The two should be independent to see that the two are distinct and can be managed independently.Content management system (CMS)CMS is a software application used to oversee the operation of web information. Common CMS applications include software like WordPress and Drupal.ContrastContrast is the perceived difference between two adjacent colours. Two colours from different segments of the colour wheel are contrasting colours. For example, red is from the warm half of the colour wheel and blue is from the cool half.Cascading style sheets (CSS)Styling for HTML.DisabilityA limitation in an ability.DiscoverabilityThe ability of any feature to be found in the context in which it is needed.Document object model (DOM)The Document Object Model is a representation of the structure of a web document. This provides a means for scripts such as JavaScript to manipulate the content and layout of a page.European Harmonized Accessibility Standards (EN 301 549)This is evolving to become the global standard for government policy. This is an evolving standard that roughly follows and extends the WCAG Guidelines.False positivesAn error in data reporting in which a test result improperly indicates the presence of a condition.Graceful degradationWhen a site utilizes new technology and, if disabled, the content maintains effectiveness for the user.Hover state and focus stateIn CSS, a hover state is when the user moves their mouse over an element such as a button or menu item, whereas the focus state is when a user focuses on an element using keyboard controls (the Tab key, typically).Hypertext Markup Language (HTML)HTML is the standard markup language used to create web pages. HTML5 is the newest version of the language with more options available to create accessible websites.InternationalizationA system whose primary design has been developed to work in multiple languages and in the cultural contexts of different locales.Information Communications Technology (ICT)ICT is an extensional term of the term information technology (IT). It refers to the gambit of technology involved in digital communications.JavaScriptOne of the most widely used scripting languages; JavaScript is a client-side programming language which can be used with almost all user agents.Late adoptersIndividuals who are hesitant to adopt new technology.LocalizationCustomizing or adapting a national or international product for a local market.Language of partsA WCAG Success Criterion for when the language of a text string is not in alignment with the page-wide definition.Luminance contrast ratioA measure of the difference between foreground and background; specific minimal values are recommended via WCAG 2.0.Mark-upA mark-up is what the browser sees. If it is marked up as a link, it can receive focus and take you somewhere else.Modal dialogue boxOften referred to as a "Modal" or "Modal Window", it is a subordinate graphical interface which opens a child window in the foreground while keeping the parent page visible but inactive.Null alt textNull alt text is including alt text within an "img", but without any content. An example would be <img alt=" ">. This should only be done for decorative images, spacers and pixels. (resource: An alt Decision Tree)Open sourceOpen Source software is a licensing model of software which gives free access to the source code of the software, allowing interested parties to modify or contribute to the software as they see fit. Commonly created as collaborative projects and shared at no cost.Programmatic focusWhere the computer's focus is on a web page.Screen readerA software program used to allow reading of content, and navigation of the screen using speech or Braille output. Used primarily by people who have difficulty seeing. JAWS and NVDA are examples for PC desktop users. Apple products come with VoiceOver for both desktop computers and mobile devices, and Android mobile devices come with TalkBack.Search engine optimizationThe process of making a website appear as highly as possible on the list of results returned by a search engine, in order to maximize the volume and quality of website traffic.Section 504Section 504 of the Rehabilitation Act of 1973. This act has implications for federal assistance and accommodation in the workplace. If an organization receives federal support of any kind, even if the organization is not a federal or state organization, the organization must comply with Section 504.Section 508Section 508 of the Rehabilitation Act was enacted to eliminate barriers in information technology, to make available new opportunities for people with disabilities, and to encourage development of technologies that will help achieve these goals. The law applies to all Federal agencies when they develop, procure, maintain, or use electronic and information technology. Until the Section 508 Refresh, this requirement was based on best practices of 1998.Section 508 RefreshThe Refresh brought the guidelines for the USA to be essentially the same as WCAG 2.0 AA.Semantic markupSemantic Markup is the idea of creating more meaning with the information in web pages and web applications. This makes it easier for devices to understand what each aspect of the code means for the end user. HTML5 markup has been optimized to allow developers to create more semantic markup.StyleStyle is what you see visually on a page, implemented with Cascading Style Sheets (CSS).TranscriptA text only version of what's said in a movie or television program; they are not real time and they generally are limited to speech only; they are not a recommended substitute for captions.UsabilityThe principle that information and applications should not only be accessible but also easy to use and understand.User agentThe generic term used to describe any device which might access a webpage.Visual focusWhere the user's focus is on a Web page. Different browsers' default focus styles may vary, and continue to be altered as browsers change.Voluntary Product Accessibility Template (VPAT™)A static document that describes how software, hardware, electronic content, and support documentation meet accessibility requirements. Generally this is aligned with the WCAG standard. VPAT™'s are defined by an industry association, Information Technology Industry Council. VPATs often required in procurement to help buyers understand how accessible a product might be and help to discover deficiencies. These are often more about marketing than reflecting the actual accessibility barriers in the product or service.WCAG 2.* (WCAG 2.0, WCAG 2,1, WCAG 2.2) {#wcag-2-*-wcag-2-0-wcag-2-1-wcag-2-2}The Web Content Accessibility Guidelines (WCAG) 2.0 is focused on providing an international technical standard for web content. It has 12 guidelines that are organized under four principles: Perceivable, Operable, Understandable, and Robust (ie. POUR). The guidelines each have a testable success criteria, which are at three levels: A, AA, and AAA.WCAG 3.0The WCAG Content Accessibility Guidelines (WCAG) 3.0.WidgetA widget is a small application installed and used on websites. Each widget has a varying amount of purposes. An example of a widget is a small, email newsletter signup form, or a third-party live chat functionality."
      
    },
  
    {
      
        "title"    : "History",
        "url"      : "/guide/history",
        "content"  : "A brief history of digital accessibility.Digital accessibility basicsDigital accessibility is both complicated and simple. It is complicated because there are many layers of technology involved in communicating content from an author to the user. It is simple because, ultimately, if you keep your site simple and follow some basic guidelines, you're generally going to achieve digital accessibility.Section 508The United States first led the movement to articulate web accessibility with the creation of Section 508 in the Rehabilitation Act of 1973. In 1998, the U.S. legislature corrected the shortcomings of the original Section 508 Amendment. This included a list of technical standards against which products can be evaluated to determine if they meet the technical compliance.WCAG and POURIn 1999 the World Wide Web Consortium's (W3C) Web Content Accessibility Guidelines (WCAG) 1.0 were published. The guidelines were built to be technology-agnostic—HTML was just one way to structure content on the web—and to accommodate the rapid pace of change online.For example, when the first iPhone was released in 2007, people had no idea how much mobile devices would revolutionize how people interact—both with digital content and each other. The web has continued to evolve rapidly. It is clear that nobody wants to create an app or a website that makes someone physically ill, but how much animation is acceptable? Where is the line between visual changes that help people identify where new content is, and the changes that cause some people to become sick?Additionally, since the WCAG process requires a great deal of negotiation—the standards must be based on evidence-based rules that have broad applicability—it isn't feasible to make specific guidelines for every disability. There are even occasions where designing a site for one type of disability (say, low vision users) will conflict with another disability (say, people with dyslexia).Rather than guidelines based on specific accommodations for particular disabilities, the W3C's Web Accessibility Initiative (WAI) settled on four key principles—known by the acronym POUR—which have guided digital accessibility. To be accessible, digital content must be:  Perceivable: users must be able to perceive the information being presented  Operable: users must be able to operate the interface  Understandable: users must be able to understand the information as well as the operation of the user interface  Robust: users must be able to access the content as technologies advanceAs the web continues to change and develop, the guidelines to maintain accessibility need to as well. WCAG 2.0 was released in 2008, 2.1 was released in 2018, and 2.2 is slated for release in mid-2021. There may be other releases within the WCAG 2.x series, and the WAI has released the first draft of WCAG 3.0, which is working to revise the whole framework.In the near future, digital tools will be expected to be personalized so that every individual can maximize their use. And while digital accessibility continues to develop, it is clear that government bodies must invest to make their technology more accessible today than before.To be clear, no website will be 100% accessible. Any work that is done should strive for excellence, not perfection. Even a site that met WCAG 2.1 AAA compliance would not necessarily be accessible to everyone. Like security, accessibility is a journey where improvements must be constantly adapted to meet changing realities. Organizations must seek to be better today than they were yesterday.WCAG guidelines should be seen not as the goal to strive for, but a floor from which to build.Other governments around the world began implementing accessibility regulations. In Canada there was the Accessible Canada Act (ACA) and also several provincial acts like Accessibility for Ontarians with Disabilities Act (AODA). Accessibility legislation occurs at all levels of government, and although there may be differences, web standards usually follow the WCAG recommendations.Harmonised European Standard & European Accessibility ActEurope is currently seen as the leader in digital accessibility best practices. The Harmonised European Standard (EN 301 549) is a living document first published by the European Telecommunications Standards Institute (ETSI) in 2014. The latest version, 3.1.1, was published in November 2019 and embraces WCAG 2.1 AA as the minimum accessibility standard for countries in the EU. Governments in the EU are given the freedom to choose how they want to implement the standard within their own countries, and after the W3C releases WCAG 2.2, it will be reviewed for consideration for an upcoming release of EN 301 549.Web content makes up a lot of the material covered in the standard, but it also includes:  computers, smartphones, tablets and TV sets;  banking ATM and services, and payment terminals;  e-books and e-readers;  mobile apps and ticketing machines.Aligning with EN 301 549 means that government accessibility efforts evolve with an ever-changing internet. Since its creation, EN 301 549 has been embraced by the UK, Mexico and Australia, and will continue to be adopted around the world. There will be costs to adopting the standard, but doing so will make it easier for companies to trade on a global stage.In 2016, the European Union (EU) Parliament and the Council of the European Union passed the EU Web Accessibility Directive. The directive aims to ensure that all Europeans can take a full and active part in the digital economy and society. EU Member states had until 2018 to adapt the Directive into national law.In 2019, the EU formally adopted the European Accessibility Act (EAA) to create a common set of accessibility guidelines for member states. When it comes into effect in 2025, the EAA will apply to businesses as well as governments across the EU—any product or service that is sold for use within the Eurozone will need to comply, including the full range of digital tools. This will include any foreign businesses that work with EU member states.The goal of the EAA is to provide unrestricted access to people experiencing any form of disability and ensure that all EU citizens can access information and services through websites, mobile applications, and electronic devices.European monitoring requirementsBy December 23, 2021, all EU member states will be required to monitor the accessibility of their public-facing websites and report on progress over time. It will be up to member states to determine how this is done, but some of them will certainly leverage open source tools to aggregate national results.In the UK, the Government Digital Services (GDS) is playing the role of the central monitoring team to assess public websites and apps. This monitoring is designed to encourage the public sector to make timely improvements to accessibility. The hope is that with active engagement with various departments, the government can avoid the need to implement further enforcement. The GDS team isn't sampling all government sites, but is prioritizing those which threaten to exclude the most people, or where there are known or suspected problems. Like others in Europe, the UK has implemented Accessibility Statements into its standard web pages so that citizens are encouraged to submit feedback when they run into barriers. This feedback loop empowers the public and highlights barriers that have been missed by automated and manual testing.In the UK, by the time a website reaches a public beta it must have monitoring in place to identify potential problems. While the monitoring instructions don't specifically state accessibility, the GDS is actively building tools to make it easier to incorporate, including a site crawler that runs on an open-source accessibility engine built by Deque Systems, called Axe."
      
    },
  
    {
      
        "title"    : "Identity and language",
        "url"      : "/guide/identity-language",
        "content"  : "People with disabilities suffer from considerable discrimination, some of which is in the form of language.When talking about people with a lived experience of disability, we want to be respectful of how people want to be identified. This changes over time, and so it is important to stay up-to-date to see that we are using the language that embraces the equality we are trying to achieve.How can we avoid ableist assumptions and Inspiration Sensationalism?Resources to help you avoid unintentionally offending people:  List of disability-related terms with negative connotations  Disability Etiquette Glossary  Disability Language Style Guide  Disability Terminology: Choosing the Right Words When Talking About Disability  AT Banter Podcast Episode 265 - Ableism Part 1  I'm not your inspiration, thank you very much, by Stella Young"
      
    },
  
    {
      
        "title"    : "Introduction",
        "url"      : "/guide/introduction",
        "content"  : "AboutThe CivicActions Accessibility guide offers guidance and information related to digital accessibility.AudienceThe CivicActions Accessibility guide is for anyone interested in digital accessibility, but we're specifically focused on supporting:  CivicActions team members  Government employees  Government contractorsContributeHow you can contribute to the CivicActions Accessibility guide:  Submit an issueQuestions?Contact us"
      
    },
  
    {
      
        "title"    : "Onboarding staff",
        "url"      : "/guide/onboarding-staff",
        "content"  : "A common understanding of accessibility allows teams to work together toward building accessible products and services. When hiring new team members, it's important to not assume they're knowledgeable about accessibility. Instead, it's best to ensure that all team members understand the basics by creating an accessibility onboarding program that every new member participates in.As part of our Accessibility Pledge at CivicActions, we've added an introduction to accessibility in our onboarding process. This has helped to advance our accessibility maturity and build a robust culture that has internalized accessibility. We'd like to share our onboarding process here in the hopes that other companies can take inspiration when building their own accessibility onboarding processes.Prepare for an accessibility workshopAll new team members attend a one hour workshop that talks about the basics of accessibility. Before the workshop takes place, we ask them to prepare by watching videos, reviewing internal company materials, and installing accessibility tools that are relevant to their area of practice.Watch accessibility videosThese short videos introduce accessibility and are a great way to get started. Each video is less than five minutes.  What is Digital Accessibility?  Introduction to Web Accessibility and W3C Standards  Disability Sensitivity TrainingReview internal materialsWe ask that new team members review the CivicActions Accessibility site and the accessibility page in the CivicActions Handbook. These are some examples of materials that you could create that would be company specific.Install accessibility toolsThese are some tools we recommend that could help test accessibility on your products.Tools for everyone  Web accessibility testers          These browser extensions evaluate web content and identify any potential accessibility issues.                  Deque's axe Browser extension          WebAim's WAVE          Microsoft's Accessibility Insights                      Color contrast checker          This tool can check if colors meet the contrast ratio defined in the Web Content Accessibility Guidelines (WCAG).                  ColorZilla for Chrome          ColorZilla for Firefox          Coolors Color Contrast Checker          WebAIM contrast checker                      Operating system accessibility settings          Investigate and configure accessibility settings in your operating system. Apple, Windows, Chromebook, Linux desktop OS all have built-in accessibility features. These can also be found on mobile systems like Android and iOS.        Browser accessibility settings          Browsers may need to be configured to enable tabbing on links.      Enabling these features makes it easy to do regular keyboard testing.      Search for these settings:                  Chrome: "Pressing Tab on a webpage highlights links, as well as form fields."          Firefox: "Use the tab key to move focus between form controls and links."          Safari (Advanced tab): "Press Tab to highlight each item on a web page."                    Tools for each practice area  Developers          Install an accessibility linter in your text editor to check your code files for accessibility defects.                  axe Accessibility Linter for VS Code                      Visual designers          Install a color contrast checker into Figma, Sketch, or Invision to ensure that the colors you choose meet WCAG contrast ratios.                  Contrast (For Figma)          A11y - Color Contrast Checker (For Figma)          Stark (For Figma, Sketch, Invision, and more)                    Better yet, install an annotation plugin to perform checks and overlay accessibility notes of all kinds on wireframes and prototypes:                  Include—Accessibility Annotations (For Figma)                      Content writers          Install a readability checker to ensure your content follows plain language guidelines.                  Hemingway App          Readable          Microsoft's Flesch-Kincaid (For Microsoft Word)                    Attend an accessibility workshopOur accessibility workshop is one hour long and covers the basics of accessibility. We encourage participants to engage with us during this time and answer any questions they may have. Our workshop covers these topics:  What is accessibility?          We discuss the different types of disabilities (hearing, motor, cognitive, and visual) and how they can be permanent, temporary, or situational.      We describe different assistive technologies people use, such as auto-captioning, text-to-speech, screen readers, and more.        Accessibility in our organization          We emphasize how CivicActions promotes accessibility with our Accessibility Pledge and how we're continuously working toward developing products built with a wide range of diversity in mind from the beginning.      We talk about our accessibility practice area and give information about internal meetings and professional development.      We review our Champions program and promote other next steps to learn more about accessibility.        Introduction to accessibility tools          We give a demo on at least one of the browser extensions mentioned above; how to use the tools on different websites, what the results look like and what they mean.      Role-specific workshops (Optional)Each role in a company may need additional support in how they can best do their job. Our team has built role based documentation that can be viewed on our Roles page. For more inspiration, we recommend these websites:  UK's DWP Guidance for your job role  Digital.gov's Accessibility for TeamsTake a quizAfter watching videos, reviewing company materials, and attending the accessibility workshop, we encourage new team members to take an accessibility quiz to help gauge their understanding of our training. Our goal is for them to score 80% or higher on this quiz or to reach out to the accessibility team with any questions they may have. To see an example of an accessibility quiz, view the quiz that we've created for new team members.CivicActions accessibility quizConclusionAccessibility onboarding is key to ensuring that all team members have a basic understanding of best accessibility practices. This understanding can help integrate accessibility into the culture of an organization and ensure that everyone on the team can help build accessible products.Resources  Microsoft's Accessibility Fundamentals Workshop  Disability:In's Disability Fundamentals Training for ManagersNext StepsWhen you are ready to learn more, here are some further guides and resources that may help:  Build up your accessibility toolbox  Invest in accessibility training  Join the global accessibility community  Build a community of practice"
      
    },
  
    {
      
        "title"    : "Organizations",
        "url"      : "/guide/organizations",
        "content"  : "  AbilityNet  Accessible Community  Disability:IN  GAAD Foundation  Knowbility.org  International Association of Accessibility Professionals (IAAP)  San Francisco Lighthouse for the Blind and Visually Impaired  W3C's Web Accessibility Initiative (WAI)  WebAIM"
      
    },
  
    {
      
        "title"    : "Plain Language",
        "url"      : "/guide/plain-language",
        "content"  : "Plain language helps make your content accessible by allowing your audience to quickly understand it the first time they interact with it. This helps people with different cognitive abilities, people whose first language isn't English, and those that rely on audio to listen to text.Plain language means that your content is written as clear and simple as possible. Good plain language will help readers find what they need, understand it quickly, and use that information to meet their needs.Basic guidelines for plain language  Use short sentences.          Try to write one idea per sentence.      Avoid repeating words.        Use simple words.          Try to keep the writing below an 8th grade reading level.      Choose words your readers use.      Imagine you're talking to your reader over the phone. What words would you use to answer questions directly?        Use an active voice.          The subject of a sentence should be performing an action.      For example, "You need to submit the form online." You, as the subject of the sentence, are performing the action by submitting the form.        Write for your audience.          People visit your website to do something. Before writing, identify the reader's needs.      How can you answer your reader's top questions quickly?      What do readers need to know or do after reading your content?        Make it scannable.          Users don't read, they scan. They often leave web pages within 10 to 20 seconds.      Structure your content with clear headers and present them in a logical order.      Use short paragraphs, bullet points, and lists to sort content into smaller sections that are easier to read.        Don't use jargon.          Business and technical jargon can be confusing. Try to use common words in place of jargon.      Spell out acronyms the first time one is used.        Don't use idioms.          Idioms are only clear to people that are in a certain group.      These can be confusing for someone whose first language isn't English.      Try to use simple words in place of phrases.      Test your contentNow that you've written your content, it's important to test it! This can help you improve your content. You can test your content using readability tools, listening to your content read aloud, and conducting user testing with your audience.Use a readability toolAlways run your content through a readability tool and try to get the reading grade level lower than 8th grade. Some common readability tools are:  Hemingway App: This app highlights content that could be hard for your audience to read.  Readable: This is a paid service that analyzes your content to identify its readability score, grammar errors, and style issues.  Microsoft's Flesch-Kincaid: This can be used with Microsoft Word to calculate your content's readability score.Use a text-to-speech readerText-to-speech (TTS) is a type of assistive technology that takes words on a digital device and reads it aloud. Simply hearing text read aloud can help authors better understand where improvements can be made. We recommend this tool:  Microsoft's Immersive Reader: In Microsoft Edge, this mode has a Read Aloud tool that can be used to read the text of a web page.User testing with your audienceAutomated readability tools won't catch everything. You'll need to test your content with humans too. When user testing, you can:  Use tree testing to discover if menu labels and other content is easy to find. This is a research method where you ask users to look for important resources.  Ask your users to read your content aloud. This can help you identify what words they may struggle with. Users can also rate the clarity of the language.  Ask your users to paraphrase what they read to gauge their understanding.Resources  Federal Plain Language guidelines  Plain Language Association International guidelines  WCAG 2.1 Reading level success criterionNext stepsWhen you are ready to learn more, here are some further guides and resources that may help your content:  Accessible documents  Social media guidelines  Additional tools"
      
    },
  
    {
      
        "title"    : "Resources",
        "url"      : "/guide/resources",
        "content"  : "BooksGeneral and digital-specific accessibility books we recommend.Commercial available  Accessibility for Everyone - Laura Kalbag  Agile Accessibility Explained Dylan Anthony Barrell  Design for Real Life - Sara Wachter-Boettcher and Eric Meyer  Designing Connected Content: Plan and Model Digital Products for Today and Tomorrow - Mike Atherton  End of Average - Todd Rose  Inclusive Design for a Digital World: Designing with Accessibility in Mind - Regine M. Gilbert  Inclusive Design Patterns - Heydon Pickering  Mismatch: How Inclusion Shapes Design - Kat Holmes  Technically Wrong - Sara Wachter-BoettcherFree  Giving a damn about accessibility - Sheri Byrne-Haber (Free)  Introduction to Web Accessibility - the Chang School (Creative Commons Attribution ShareAlike)  Understanding Document Accessibility - the Chang School (Creative Commons Attribution ShareAlike)  Web Accessibility for Developers - the Chang School (Creative Commons Attribution ShareAlike)  Professional Web Accessibility Auditing Made Easy - the Chang School (Creative Commons Attribution ShareAlike)  Digital Accessibility as a Business Practice - the Chang School (Creative Commons Attribution ShareAlike)Newsletters  A11yweekly.com by David A. Kennedy  Accessibility Matters Newsletter - by the IAAP  Microassist's Accessibility in the News -  by Jack McElaney  More available from WebAxe who maintains a terrific listPodcastsAccessibility related podcasts we recommend.  13 letters - Engaging interviews about the people behind assistive technology. Produced by Be My Eyes.  Be My Eyes Podcast -  Stories about living blind in a sighted world.  A11yrules - Interviews with people with lived experience of technology.  AT Banter - Lively discussion about issues related to assistive technology.  Human Potential at Work - Episodes with people addressing issues of accessibility in the workplace.  IAP Podcast - Interviews on accessibility digital accessibility supported by TPGi.Videos  AXSChat - The videos behind the weekly #axschat Twitter chat  A11yTalks  Accessibility London  AbilityNet  DigitalGov Accessibility Playlist - A YouTube Playlist built by the USA Government  Eric Eggert series - Eric Eggert walks through many high level  Erik Kroes series - Eric Kroes does live reviews of websites and teaches by doing  Heydon's Webbed Briefs series - A very entertaining and informative series of videos  WAI Web Accessibility Perspectives Videos - A short list of videos from the W3CGovernment-developed accessibility resources  Accessibility Guide by 18F -18F Guide on GitHub  Accessibility for Teams USA Gov -Accessibility for Teams on GitHub  Accessibility Manual by UK's DWP -Accessibility Manual on GitHub  Accessibility Posters by UK's Home Office Digital -Posters on GitHub  Digital Accessibility Toolkit by the Government of Canada -Digital Accessibility Toolkit on GitHub  AccessAbility Playbook: Tools for accessible client service by the Government of CanadaMore inspiring open content  a11y.css -a11y.css on GitHub  A11yProject.com -A11yProject.com on GitHub  A11ysupport.io -A11ysupport on GitHub  A11y.coffee -A11y Coffee on GitHub  Accessibility Guidelines by Voxmedia -Accessibility Guidelines Checklist on GitHub  HTML5 Accessibility by Steve Faulkner -HTML5 Accessibility on GitHub  Accessibility Developers Guide (ADG) - ADG on GitHubDrupal accessibility modules  Accessibility Scanner - Sitewide Drupal Scan (axe)  A11Y: Form helpers - Fixing form issues like the HTML5 validation.  Block ARIA Landmark Roles - Adding semantics to blocks  CKEditor Abbreviation - CKEditor Plugin  CKEditor Accessibility Auditor - WYSIWYG Scanner (HTML CodeSniffer)  Editoria11y - WYSIWYG Scanner (Tota11y)  Fluidproject UI Options - Preference Editor Widget  High contrast - High Contrast Module  htmLawed - HTML Validity Filter  HTML Purifier - HTML Validity Filter"
      
    },
  
    {
      
        "title"    : "Semantic HTML and accessibility",
        "url"      : "/guide/semantic-html",
        "content"  : "When a contractor builds a house, they tend to use standard and expected materials that are appropriate for their purpose—i.e. concrete, wood, shingles, etc. Using standard materials helps to ensure the house is built well. If other materials are used instead, the house might require additional work to achieve the same end result. If the Three Little Pigs have taught us anything, unless it's reinforced, a house made of straw can't be expected to withstand strong winds.This same principle is true when building a website—there are standard building blocks for each section, typically referred to as semantic HTML tags. Using these tags gives the resulting website more structure and context than building with other, generic tags. Semantic HTML tags also provide some default accessibility to the page elements that would otherwise need to be reinforced using additional, custom code.What is semantic HTML?When someone says that you should be building using semantic HTML, what does this actually mean?Semantic markup refers to the HTML tags that define the meaning and structure of the content they contain. There are many semantic tags but a few common examples are:  <header>: This represents the header or introduction of the website. This is typically the area that contains the site logo and global navigation.  <main>: This is for the main body content of the webpage. There should always be only one main section on each page.  <a>: This tag is sometimes referred to as the anchor element and is used for a link. A link element has an href attribute and goes somewhere, to a new page on the website or an external page on another website.  <button>: This represents a button element. A button element is for an action that does something, such as opening a modal or submitting a form.  <li>: This tag represents an item in a list. This tag must be contained within a <ul> tag (unordered list) or an <ol> tag (ordered list) or <menu> tag.There are also other, generic tags such as <div> and <span> that do not define any meaning and therefore are not considered semantic tags.Here's an example of the same element written with and without semantic tags:Example 1 - Generic tags:<div>  <div>    <span><a href="/">Home</a></span>    <span><a href="/about">About Us</a></span>    <span><a href="/contact">Contact</a></span>  </div></div>Example 2 - Semantic tags:<nav>  <ul>    <li><a href="/">Home</a></li>    <li><a href="/about">About Us</a></li>    <li><a href="/contact">Contact</a></li>  </ul></nav>In the first example, using generic tags, without the visual of the website itself, it's hard to clearly understand what the purpose of this code is for. There are 3 links, grouped together but why exactly it's not clear.In the second example we clearly see semantic tags for a navigation menu (<nav>), containing an unordered list (<ul>) with 3 links. There still is no visual but from just the implicit meaning of the tags, it's understood that the purpose of this code is to provide a navigational list element for the website.Why use semantic HTML?Besides providing clear structure and contextual information to your HTML document, semantic tags will also inherit default styles from the user-agent stylesheets. Each browser, or user-agent, provides a basic set of CSS rules that define how semantic HTML elements will visually render. These rules can include underlining links, a larger font-weight for bold text, backgrounds on buttons, etc. By already having basic styles on certain elements, specifying additional CSS is not always needed which can make your work more efficient.A further benefit of using semantic HTML tags is that along with the default CSS styles, they also provide some basic accessibility functionality, no additional custom code is required,Keyboard functionalityOne of the main benefits of using semantic HTML tags is that by default, they provide the required keyboard functionality needed for accessibility. At a minimum, all interactive elements on a webpage must be available and focusable using the TAB key. They must also respond appropriately to expected keyboard keys. Typically, these keys are ENTER and SPACE, however for certain elements the ARROW keys or ESC key, among others, are expected. Each element has different default behavior and by using the standard semantic tag, you will be getting this default functionality and behavior for free.For example, if an element is created using the <button> tag, a user will be able to tab to the button and will be able to activate it using both the SPACE and ENTER keys. However, another element styled to visually look like a button but created using a generic <div> tag will not have this default keyboard functionality and this interaction will need to be added using additional code, typically JavaScript.ExampleUsing the keyboard, try to tab to the two buttons. Notice that only the first, semantic button receives proper keyboard focus.A semantic buttonGeneric buttonLandmarksPeople using assistive technology often navigate a webpage by using the landmarks on a page. However, these sections need to first be identified as such in order for this to be possible. The 7 sections that should be identified on each page are:  role="banner":  Semantic equivalent is <header>  role="navigation": Semantic equivalent is <nav>  role="search": Semantic equivalent is <search>  role="main": Semantic equivalent is <main>  role="complementary": Semantic equivalent is <aside>  role="form": Semantic equivalent is <form>  role="contentinfo": Semantic equivalent is <footer>Structuring web pages using the equivalent semantic tag rather than the role attribute, means these sections will be identified by default, no landmark role will be forgotten, and the user will be able to clearly understand the structure and layout of the page as well as navigate directly to a particular landmark if they choose.Assistive technologyAs with landmarks, assistive technology users, especially those using screen readers, also often use the menus within their software to view a full list of other elements on a page, such as headings, links, buttons or forms. Using that list they can get a sense of the content on the page and can also  jump directly to a particular element if they want.However, only the elements built using semantic HTML tags will be available to these assistive technologies and displayed in these menus. Generic elements, even if they are styled to look like headings, links or buttons, will not be shown in these menus which could cause users to miss important content.Resources  List of semantic elements  Semantic Structure  More information about the div tag  HTML and landmark roles"
      
    },
  
    {
      
        "title"    : "Social Media",
        "url"      : "/guide/social-media",
        "content"  : "Social media is used to create and share ideas, information, and interests. Accessible social media content allows people with disabilities to engage with these virtual communities instead of being shut out of the conversation. Taking steps to make your social media content accessible means that more people will be able to engage with it!Basic guidelines for social media  Keep text as clear and simple as possible by using plain language.          Use short sentences and choose words your audience uses.      Don't use all-caps.      Spell out abbreviations or acronyms.      Include descriptive text before links. For example, "Read the help page for more info: (LINK)"        Add alternative text to all contextual images.          Avoid images with text on them.      Use static images instead of animated GIFs      Make sure images have strong color contrast.        All videos should have captions and transcripts.          Don't forget to review any auto-generated text.        Be thoughtful about the use of hashtags.          If using hashtags, write them in camel case. This means that each unique word in a hashtag should start with a capital letter. This makes it easier for assistive technology to pronounce hashtags. For example, #WebAccessibility        Limit the use of emoji and special characters.          Use words instead of emojis to describe things.      Add emojis at the end of messages.      Be aware of how screen readers voice emoji and special characters—it can change the meaning of your posts. Special characters can have long spoken names when voiced by a screen reader, burdening some of your users more than others.      Resources  Accessible Social's free resource and education hub for social media  Digital.gov's toolkit for improving the accessibility of social media in government  Planning, creating and publishing accessible social media campaigns  How to make images accessible for people on X (formerly Twitter)Next stepsWhen you are ready to learn more, here are some further guides and resources that may help your social media:  Plain language guidelines  Additional tools"
      
    },
  
    {
      
        "title"    : "Tools",
        "url"      : "/guide/tools",
        "content"  : "Digital accessibility tools.Authoring  A11yFirst for CKEditor - Accessibility First on GitHub Series of plugins for supporting a11y best practices within the WYSIWYG editor, CKEditor.  Sa11y, the accessibility qualityassurance assistant An in-page accessibility checker that visually highlights common accessibility and usability issues. Geared towards content authors, Sa11y straightforwardly identifies errors or warnings at the source with a simple tooltip on how to fix them. Available as a JavaScript plugin, bookmarklet, and WordPress plugin.  Editoria11y - Editoria11y was initially built on Sa11y and highlights common issues inline with the content editor. Presently there is a Drupal module that leverages CKEditor, but they are working on a WordPress module too.  retextjs: retext-readability plugin A plugin for retext that scans text content for readability (defaults to age 16 reading level, but is configurable) and warns developers of issues.  retextjs: retext-equality plugin Another plugin for retext that checks text content for possible insensitive, inconsiderate language.  Zettlr: Markdown Editor - Zettlr on GitHub Open source Markdown editor that simplifies the content creation experience by avoiding the clutter seen in many common word processing solutions.  Drupal is a very accessible CMS and these modules can enhance its accessibility  ATOM Plugin - web-accessibility-checker package An accessibility Plugin for the popular open source ATOM Editor from GitHub.Assistive technology  NVDA - NVDA on GitHub Available for PCs running Microsoft Windows 7 SP1 and later, NVDA is a fast, functional, and free screen reader.  ChromeVox Chrome Extension - ChromeVox as part of ChromeOS on GitHub - Install and Setup Instructions from Web Accessibility for Developers Guide (with video) A fully featured screen reader for the web built using only web technologies such as HTML and Javascript. This extension specifically works within the Chrome browser to read content aloud.  Android Talkback & Switch - on GitHub TalkBack is the Google screen reader included on Android devices. Switch lets you interact with your Android device using one or more switches instead of the touchscreen, useful if you can't interact directly with your device.  Apple VoiceOver While not open source, VoiceOver is an industry‑leading screen reader for Apple products, which also gives descriptions in braille.  Linux Orca - Orca on GitLab - Orca on Chrome/Chromium Orca is a free, open source, flexible, and extensible screen reader that provides access to the graphical desktop via speech and refreshable braille.  SkipTo Landmarks & Headings on GitHub based on PayPal's skipto HTML project SkipTo provides a browser extension that provides keyboard only user more navigational control.Site-wide evaluation  bbc-a11y on GitHub Highly-configurable bbc-a11y runs a set of tests against a set of URLs to verify whether each one meets the BBC accessibility guidelines.  Domain Accessibility Audit by MSU College of Natural Science on GitHub This web application automatically crawls websites, checks for accessibility violations, and is based on axe.  GOV.UK Accessibility Reports on GitHub A collection of reporting tools that run on Amazon's S3 infrastructure. Geared to crawl a large number of webpages, like Gov.uk.  Pa11y - Pa11y on GitHub A popular command-line interface which loads web pages and highlights any accessibility issues it finds. The Pa11y family of applications includes a Dashboard for monitoring several projects' a11y issues, as well as continuous integration (CI) abilities.  Purple A11y by Government Digital Services, Singapore and Purple A11y Desktop on GitHub Powered by axe, Purple A11y (previously Purple Hats) is a customisable, automated accessibility testing tool.  Unlighthouse on Unlighthouse on GitHub, helps you crawl your site with Google Lighthouse.Page level evaluation  A11ygator - A11ygator on GitHub An application and Twitter bot that quickly tests single pages against WCAG.  Accessibility Insights by Microsoft - Accessibility Insights GitHub Page Feature-rich testing suite for reviewing/auditing a11y on web sites, Android apps and Windows apps.  Accessibility Toolbar Plugin - ACC Toolbar on GitHub A component you can add to your site which adds tools that give people with vision disabilities a way to change text size, contrast level, etc…  axe by Deque - axe GitHub Page A leading testing toolkit that powers many other projects and offers different levels of usage, through browser extension tests or within continuous integration via their API.  bbc-a11y on GitHub This tool runs a set of tests against a set of URLs to verify whether each one meets the BBC accessibility guidelines. Can be run from the command line and added to continuous integration pipelines.  Google Lighthouse - Lighthouse on GitHub Extremely flexible and popular testing suite from Google that can be run directly on pages, from the command line, or as a Node module.  IBM Equal Access Toolkit - equal-access on GitHub Tools from IBM that can automate accessibility testing from a browser, or when added to a continuous integration environment.  Explore ARIA Landmarks Browser Extension - Landmarks on GitHub Browser extension that allows you to navigate a web page via WAI-ARIA landmarks, using the keyboard or a pop-up menu.  Firefox AInspector WCAG - A Firefox Add-on that addresses accessibility compliance using OpenAjax Alliance rulesets.  Qualweb - Qualweb on GitHub - A set of tools that are being built to align with the W3C's ACT ruleset.Bookmarklets  ANDI by SSA.gov - ANDI on GitHub A free accessibility testing tool that offers detection of problems and shows what a screen reader should say for interactive elements. It also gives realistic recommendations to improve accessibility, and checks 508 compliance.  Touch Bookmarklet - Touch on GitHub Simulate touch events (swipe, rotate, pinch) with a mouse.  Outline ⭐️ Bookmarklet on Codepen (MIT Licence) On click, every focusable element will receive a red border, so you can see where the keyboard cursor is.  What has focus? on Codepen (MIT Licence) When something receives keyboard focus via Tab key, the current element will be logged to the JavaScript console so you can determine which element currently has focus.  Reading Order Bookmarklet Running this bookmarklet will visually number the reading order in which screen-reading software will announce different parts of the page, to check to see that it matches the visual order (up to down, left to right).  Accessibility and Contrast Bookmarklet - Contrast Bookmarklet on GitHub Analyse the contrast of the text on a page and highlight elements which may have readability issues.  WAI-ARIA-Usage by The Paciello Group Evaluate WAI-ARIA according to the ARIA in HTML specification.  Paul Adam's Collection of JavaScript Bookmarklets for Accessibility TestingColorWeb based contrast tools  Contrast Finder by Tanaguru - Contrast Finder GitHub Page  Contrast-Ratio.com - Contrast-Ratio GitHub Page Allows for testing of contrast of text on top of a semi transparent background.  Contrast Checker  ButtonBuddy - ButtonBuddy on GitHub  ACD (Previously ColorCube) - ColorCube on GitHub  LeonardoColor.io  - Leonardo on GitHub  Colour Contrast Checker - Colour Contrast Checker on GitHub  Who Can Use - Who Can Use on GitHub  Colour Contrast Analyser (CCA) by TPGi - CCA on GitHubCreating color palettes  Accessible color palette builder - Accessible Color Palette on GitHub  Contrast Grid - Contrast Grid on GitHubColor browser plugins and apps  Colour Contrast Analyser (CCA) by TPG - CCAe on GitHub  Eye Dropper Chrome Extension - Eye Dropper on GitHubDetermine the contrast ratio of two colors using an eyedrop tool on Windows and Mac.  Pika MacOS Color Picker - Pika on GitHub Open-source, native colour picker for macOS.Color integrations for design tools  Color Contrast Analyser for Sketch on GitHub Sketch plugin that calculates the color contrast of two layers and evaluates it against the WCAG.Design tool accessibility integrationsFigma  Accessibility Annotation Kit - a community plugin for Figma that helps designers document accessibility considerations to share with developers when handing off designs.  Accessibility Checklist for Designers - a checklist was created on the base of WCAG 2.1 AA standards.  Inclusive Design illustrations -  character stickersheets and illustrations from Microsoft Inclusive Design's toolkit.  Intopia's accessibility annotation kit - communicate your accessibility requirements to developers and testers.  A11y Annotation Kit - document accessibility considerations to share with developers when handing off designs.  Twitter's Accessibility Annotation Library - efficient, and scalable way for designers to communicate needs to engineers.Sketch  Sketch Accessibility Assistant - a linter for compliant color contrast and type based on WCAG 2.1.  Sketch cluse.cc or cluse on GitHub - Sketch Plugin to check and adjust color contrast accessibilityStorybook  storybook-addon-a11y or Addon A11y on GitHub - a Storybook addon which uses axe to improve the accessibility of UI components.  storybook-a11y-report or A11y Report on GitHub - crawl Storybook pages and produce a report  Aria Live or Addon Aria Live on GitHub - an utility tool for inspecting announcements of ARIA live regionsAutomated testing & continuous integration  Cypress-axe Testing with Cypress on GitHub  Jest-axe Testing with Jest on GitHub  Nightwatch aXe-core Testing with Nightwatch on GitHubSimulators & building empathy  Metamatrix Web Disability Simulator Chrome Extension on Metamatrix on GitHub Simulates color blindness, low vision, dyslexia and more.  Funkify Chrome Extension Not open source, but a free version is available which simulates dyslexia and cognitive/motor/vision conditions.  Sim Daltonism - sim-daltonism on GitHub iOS/Mac app that lets you visualize colors as they are perceived with various types of color blindness.  A11Y: Color blindness empathy test on GitHubChrome/Firefox extension and a web-based tool created to help designers and developers better understand color blindness and visual imparity.  Color Oracle - Oracle-Mac on GitHub & Oracle-Windows on GitHub Color blindness simulator for Windows, Mac, and Linux.EPUB3  EPUBCheck  Ace, by DAISYPDFsAccessibility checkers  PAC 3  PAVE  VeraPDF  simplA11yPDFCrawlerParsing/manipulating PDFs (not a11y-focused)  PDF ParserOther lists of tools  Donna Bungard's An Incomplete List of Tools for AccessibilityGoogle spreadsheet tracking the feature sets and various aspects of several popular tools.  Paul J Adam's Resources List  Accessibility Lists of Lists  Web Accessibility Evaluation Tools ListVideos  WebAim's WAVE Introduction to the WAVE Toolbar.  Microsoft's Accessibility Insights Introductory Videos about use of Accessibility Insights.  Deque's Axe Get started with using axe."
      
    },
  
    {
      
        "title"    : "Training and Certifications",
        "url"      : "/guide/training",
        "content"  : "Ready to learn more about accessibility? Whether you're just starting or already have some basic knowledge of accessibility, we have resources that can help with your continued education.Certificates for demonstrating accessibility knowledgeAt CivicActions we encourage all employees to start with the W3C's EdX course. It provides a solid introduction to the topic for anyone whose work relates to the creation of digital content and products. The additional courses listed here are well-regarded in the United States, and IAAP's CPACC and WAS courses are internationally recognized.  W3Cx: Introduction to Web Accessibility  Certified Professional in Accessibility Core Competencies (CPACC)  Web Accessibility Specialist (WAS)  DHS's Section 508 Trusted Tester Conformance Test ProcessChampions program for CivicActions employeesCivicActions employees who are committed to learning and promoting accessibility are known as Champions. Champions are responsible for fostering awareness and action on digital accessibility within their teams. Our program has three levels that suggest different training and certificates to help people increase their accessibility knowledge. This information might also be of interest to employees of other organizations interested in developing their own internal advocacy programs.Learn more about the Champions levelsNext stepsWhen you are ready to learn more, here are some further resources that may help:  Accessibility Organizations  Accessibility Resources  Our Champions program"
      
    },
  
  
    {
      
        "title"    : "Accessibility Avery",
        "url"      : "/personas/accessibility-avery",
        "content"  : "DescriptionAvery is really up on the standards and best practices on accessibility in the world. They don't have a GitHub account, but they want to contribute to the community. Avery wants to ensure their government employer keeps up.Avery has terrible allergies in the spring, and they sometimes get massive migraines that stop them from being productive.GoalsBring together recommendations for management about how to improve our siteNeedsFormatted text with larger letters, different font, more spacing, and responsive designThoughtsWonders if there is a link within the plain text that isn't being emphasizedFeelingsDisoriented with ornamental animations, especially after staring at a screen all dayBehaviorsOften magnifies screen up to 200% to focus on specific textPain pointsWebsites with small text and poor color contrast that keep Avery from identifying their location on a page"
      
    },
  
    {
      
        "title"    : "Designer Darcy",
        "url"      : "/personas/designer-darcy",
        "content"  : "Darcy is a fantastic designer who is able to express complex data tables and help people visualize complex ideas very easily. They are a terrific story teller and are able to do so with a combination of images, text, and even videos.They feel that they can do their best work outside in the sun. They do all they can to shade their screen, but often there just isn't enough contrast. Darcy needs the ability to shift to high contrast or dark mode to be able to see better in different conditions.Goals  Finding tools and techniques that would help them implement more inclusive designs  Understanding when and where accessibility checkpoints fit in the design processNeeds  Ability to control the contrast of the website on their laptop.  Resources for testing with people with disabilities  Understanding how to include video/motion in designs in an accessible wayThoughts  Do my designs pass the checklist to meet accessibility standards?Feelings  Worries the site's lack of visibility in the sun will force me to go back inside to complete my taskBehaviors  Evaluating designs for accessibility through online checklistsPain points  Information architecture that doesn't allow them to find what they are looking for"
      
    },
  
    {
      
        "title"    : "Engineer Emery",
        "url"      : "/personas/engineer-emery",
        "content"  : "Emery is always on GitHub and forking projects they are curious about. They have made over 1000 contributions this year and issues lots of PR's. Emery manages two FOSS projects and is always looking for ways to improve them. Some of their projects involve accessibility, so they want to learn more. Emery is often learning from StackExchange and posting questions to the community there.Emery just has one eye, but that doesn't stop them. Unfortunately, some VR solutions don't work for them, and they feel sick if there is too much animation on the screen.GoalsLearning best practices about accessibility, particularly for dynamic sitesNeedsAbility to turn off animations or possibly run the site without JavaScriptThoughtsWill the site have motion on it that makes me feel sick?FeelingsWorried the site won't respect my need for reduced motionBehaviorsSometimes disables images on their browser to not worry about themPain pointsSites that are visually more complicated than needed"
      
    },
  
    {
      
        "title"    : "Procurement Parker",
        "url"      : "/personas/procurement-parker",
        "content"  : "DescriptionParker is responsible for evaluating large procurement projects for government departments. They've taken the DITAP course, so they are familiar with agile and how that plays into procurement. They aren't very familiar with accessibility, but they know they have to do more than insert a line about 508 into an RFP.Parker is hard of hearing and has trouble communicating with people over the phone. They prefer communications over email where they make sure they understand.GoalsFind appropriate accessibility provisions, clauses, and acceptance criteria for their reportNeedsVideos with Closed Captions, subtitles and/or transcriptsThoughtsIf there are videos with this site it would be captioned, right?FeelingsFrustrated when closed captions are out of sync or have poor contrastBehaviorsFacial expressions and body positions to convey meaning and fill in missing information. They search for accessibility and procurement and land on a page of our sitePain pointsContact Us pages that do not have secondary and tertiary means of communication."
      
    },
  
    {
      
        "title"    : "QA Quincy",
        "url"      : "/personas/qa-quincy",
        "content"  : "DescriptionQuincy is always on top of testing. They enjoy breaking websites to make sure they meet criteria for accessibility, and they care about security and performance of the site. They look at automation because testing can take time.Quincy has a rotator cuff injury and needs to use the keyboard exclusively for a few weeks.GoalsLooking at best practices for QA automationNeedsAbility to navigate websites without using a mouseThoughtsHow can I further automate my process? Is this accessibility information up-to-date?FeelingsTime-pressured for QA workBehaviorsQuickly scans content and misses the fine detail. If it's not a bullet point, they won't read itPain pointsTasks that can't be automated"
      
    },
  
    {
      
        "title"    : "Remote Raz",
        "url"      : "/personas/remote-raz",
        "content"  : "Raz wants to work for CivicActions and is keen to see what projects they are involved in. They are keen to work in civic tech because they feel they can have a bigger impact by improving government. They love the great outdoors and are often travelling around to explore the world.Raz is often trying to connect from a camping ground over their cell phone. They turn off images and minimize bandwidth aggressively to be productive.GoalsRaz needs to focus on the work and wants to avoid any additional bandwidth.NeedsAbility to turn off anything that gets in their way.ThoughtsWhat am I missing?FeelingsWorries about delays due to slow internet speeds and high bandwidth costs.BehaviorsOften Raz is engaging in non-peak hours in order to avoid the data "rush hours".Pain pointsHaving to search for another coffee shop to manage their more high-bandwidth data transfers."
      
    },
  
  
    {
      
        "title"    : "Drupal",
        "url"      : "/projects/drupal"
      
    },
  
    {
      
        "title"    : "USWDS Color Tool",
        "url"      : "/projects/uswds-color"
      
    },
  
    {
      
        "title"    : "U.S. Web Design System",
        "url"      : "/projects/uswds"
      
    },
  
  
    {
      
        "title"    : "Designer",
        "url"      : "/roles/designer"
      
    },
  
    {
      
        "title"    : "Developer",
        "url"      : "/roles/developer"
      
    },
  
    {
      
        "title"    : "Executive",
        "url"      : "/roles/executive"
      
    },
  
    {
      
        "title"    : "Operations",
        "url"      : "/roles/operations"
      
    },
  
    {
      
        "title"    : "Procurement",
        "url"      : "/roles/procurement"
      
    },
  
    {
      
        "title"    : "Product manager",
        "url"      : "/roles/product-manager"
      
    },
  
    {
      
        "title"    : "Project manager",
        "url"      : "/roles/project-manager"
      
    },
  
  
    {
      
        "title"    : "Design",
        "url"      : "/topics/design"
      
    } ,
  
    {
      
        "title"    : "Disability type",
        "url"      : "/topics/disability-type"
      
    } ,
  
    {
      
        "title"    : "Process/Policies",
        "url"      : "/topics/process-policies"
      
    } ,
  
    {
      
        "title"    : "Roles",
        "url"      : "/topics/roles"
      
    } ,
  
    {
      
        "title"    : "Testing",
        "url"      : "/topics/testing"
      
    } ,
  
    {
      
        "title"    : "Tools",
        "url"      : "/topics/tools"
      
    } 
  
]