Define the CivicActions approach to accessibility - open & agile

[mgifford]

These are two areas we're known for. We need to explain how they are related to accessibility

Open

• There's a stub for this here https://civicactions.github.io/accessibility/open with links out to related topics/resources.

Agile

• Someone has to write this

Agile Resources

• https://accessibility.deque.com/agile-accessibility-handbook
• https://www.deque.com/blog/accessibility-in-agile-transformational-practices/
• https://accessibility.deque.com/intro-to-agile-accessibility
• https://www.deque.com/blog/accessibility-in-agile-team-practices/
• https://developer.paciellogroup.com/blog/2017/03/accessibility-in-an-agile-lifecycle/
• https://knowbility.org/programs/accessu/2020/accessibility-in-an-agile-methodology/
• https://www.levelaccess.com/resources-2/topics/agile-and-accessibility/
• https://karlgroves.com/2011/09/28/agile-accessibility
• https://www.planittesting.com/in/insights/2017/implementing-accessibility-in-agile-projects
• https://strippokerstoriesofhu19838.blogspot.com/2019/06/get-agile-accessibility-explained.html

Related issues

• Define CivicActions accessibility offering https://github.com/CivicActions/accessibility/issues/41

[dmundra]

Additional links:

• https://accessibility-for-teams.com/article/accessibility-in-the-definition-of-done
• https://uxdesign.cc/inclusive-user-archetypes-b834ffbdb549

[dmundra]

Hi @mgifford and @lukefretwell, I started a google doc to draft the Agile language: https://docs.google.com/document/d/1jqZuvdMxPi9aSsFcu0Oa387SNo7d1y-2ViMSsEbdiYE/edit?usp=sharing. I am not an expert at wordsmithing but my take is to inject accessibility into some highlighted agile practices (a little bit scrum heavy).

In creating that I also think we should highlight teams and projects that already do them or similar items and come up with a list of items for teams to try.

That is where my thoughts are at. What do you folks think?

[mgifford]

I think it should build on whatever we've defined in blogs and articles but especially the handbook https://handbook.civicactions.com/en/latest/050-how-we-work/agile-overview/#agile-overview

Who leads our Agile process. Probably would be good to engage with them on this.

[dmundra]

@mgifford, I can put a question in the #agile/#accessibility channel to see who is willing to comment on it. My other thought is just like the 'Open' section is local to 'CivicActions Accessibility' the agile section can also be localized and maybe aspirational?

Also, what do you think of the list of examples? I can also add that question but we can pursue that later.

[mgifford]

We should begin the conversation with those responsible. Maybe get them to engage with this thread here. Perhaps there is already some existing documentation. I do think we can list/aggregate best practices here. Simply outlining how we would like to be integrating it would be useful.

[dmundra]

Hi @akaroleff, please take a look at this thread and we would love your input and direction on defining accessibility with agile. Also if you recommend others we should include in the discussion please let us know.

[dmundra]

A possible list of questions to ask folks on how have they incorporated accessibility into their project (could be a poll but I also would like examples with documentation and details on how they do it):

• 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 stories.
• Creating accessibility specific stories.
• Using accessibility testing tools when developing a feature locally.
• Using accessibility testing tools when testing a feature in QA.
• Using accessibility testing automation tools when pushing code to branches.
• Using accessibility testing automation tools when deploying code to infrastructure.
• Using accessibility testing tools when testing a feature in production.
• Relying on the client for accessibility testing.
• Post project completion accessibility testing.
• All of the above.
• Other.

@mgifford what do you think of this list? add, remove, or combine items?

[mgifford]

I've been talking with Michelle Kang about personas/archetypes. Earlier I wrote this - https://github.com/mgifford/Personas

Hopefully some of the automated testing stuff will come out soon in an article that will be published soon. CA folks can see what we are trying to publish here https://docs.google.com/document/d/1vDFGrfmtVBzZXI5sJND-qsZt8QWnFtQ02w3MCJ8cAng/edit?usp=sharing

Accessibility testing is great, but it only gets about 1/3rd of the issues - https://alphagov.github.io/accessibility-tool-audit/

Your point though is key. Each step of the process and each role may want to use different tools. I've been highlighting some of what folks are doing here https://github.com/CivicActions/accessibility/issues/42

With automated tools, it might be better for some to use axe & others to use the WAVE Toolbar. There are benefits to both (but also disadvantages to both). There is a real assortment to tools, but it's a matter of finding the right tool for the role. A list of great open source tools is coming together here https://civicactions.github.io/accessibility/handbook/tools

There's a list of questions we're using here with clients (internal) but there are ideas that could apply to our own teams.

[dmundra]

Thank you for sharing the links, agree with all points. I like the 'Layered Accessibility Testing' article and it would be great to share it once published.

[mgifford]

I’m happy to hear that Daniel.

I’d love to work on an article with you at some point too.

Mike

On February 3, 2021 at 11:23:33 AM, Daniel Mundra (notifications@github.com) wrote:

Thank you for sharing the links, agree with all points. I like the 'Layered Accessibility Testing' article and it would be great to share it once published.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/CivicActions/accessibility/issues/40#issuecomment-772634904, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAA4QYHYOWXE3ET5B5Q33SLS5F2ALANCNFSM4WSJWKZA .

[dmundra]

@mgifford here is a survey https://docs.google.com/forms/d/1ZEoGwrEi0I0GWTNS138rrgyei-apDWXhz95Gh3HgR-M/edit?usp=sharing to solicit how existing projects are working with accessibility and I also ask what they wish their project was following. Useful? I am curious to collect that information and I can convert it into a slack poll. Maybe in the next practice area meeting, we can share it with folks?

Preview: https://docs.google.com/forms/d/e/1FAIpQLScHszOkRiECyRn7YzG2dWMqdumqwaSplM_nscxKstFF6YnVcg/viewform

[mgifford]

This is interesting. I'm not sure. Might be good to see what someone in a PM role says. I've read a bunch about it, but I never needed to formalize this with the projects we were working on before.

Might be more useful to ask short polls in Slack first. I find that when folks see a wall of checkboxes it can be overwhelming. Initially this is just to gage adoption and inspire conversations.

I wonder about talking about involving people with lived experience with disability.

I edited it a bit to add some other options. I'm interested in the process, but think we could use some guidance on how to improve this.

[dmundra]

Hey @stevecurtis, here is the full thread about agile & accessibility. I wanted to check-in with you whether you had any input on the document and our current ideas of a survey. Mike is also going to check-in with you.

cc: @mikang

[dmundra]

@mgifford started the site page in the PR above and also modified the survey after I realized I could reduce some of the options.

Maybe in the slack channel, we should only ask the first bank of checkboxes for existing projects to gauge interest.

@mikang can you also review the survey and the document?

[dmundra]

Attended https://www.accessibilityassociation.org/content.asp?admin=Y&contentid=749

Notes:

• Testing/audit at the end, too costly to fix accessibility issues at the end of a project. They are put in the backlog and never fixed.
• Accessibility expert provided user stories for requirements.
  • Stories that also have accessibility acceptance criteria can become large so maybe splitting by the user types (accessibility personas/archetypes?) would be better.
• Decorative images use empty alternate text i.e. alt="". Also, look at https://www.bbc.co.uk/accessibility/forproducts/guides/mobile/decorative-content/ for iOS and Android.
• Design iteration should include simple color checks.
• Check on team acceptance (working agreements?), and ensure all understand the importance of adding in accessibility.
  • Empathy exercises (example exercise use keyboard only to do a task on a website).
  • Wage incentive, bonuses, and/or performance-related incentives.

A takeaway, we are on the right track with our agile and accessibility theory.