Will there be a VPAT? What is the Accessibility Roadmap?

[mgifford]

There are lots of accessibility issues listed already:
https://github.com/microsoft/BotFramework-WebChat/issues?q=is%3Aissue+is%3Aopen+accessibility

Is there going to be a VPAT for this? More importantly, what is the road map to address these issues?

People expect Microsoft products to be accessible. Chatbots are complicated. This doesn't look like it has been built with best practices around semantic HTML5.

I'd just like to know if this is a product where we can expect to see improvements.

[corinagum]

Thanks @mgifford for filing this issue. We care deeply about Accessibility and use the Accessibility label to track our Accessibility-related issues. Accessibility label issues

Currently there are 4 issues that have open PRs, and will be merged in for our next release. To see more information about accessibility on this project, please see our Accessibility documentation.

Accessibility is one of the top priorities for our team, and we undergo regular audits to ensure we meet MAS requirements. We work continuously with customers to resolve accessibility problems and continue to improve our product. I'd be really interested to see specific examples of non-semantic HTML in our project, as this is one of the base rules that we prioritize when developing new features and fixing existing ones.

Does your request for a VPAT mean you are looking for a public checklist of what requirements we meet and don't meet?

You are more than welcome to file specific accessibility problems that you find, and we will prioritize them accordingly. Because we are continuously adding new accessibility to the project, please be sure to test out our latest version, 4.11.x

[corinagum]

@Virtual-Josh hahaha, apparently GitHub doesn't like us editing labels at the same time. Reverting them back, fyi

[compulim]

FYI, we follow Microsoft accessibility policy for products. We are compliant to WCAG 2.1, EN 301 549, and Section 508. You can find our conformance report here, https://cloudblogs.microsoft.com/industry-blog/government/2018/09/11/accessibility-conformance-reports/, under the product of Azure Bot Services.

As @corinagum mentioned, accessibility is our top priority.

There are a few reasons why we have ongoing accessibility issues:

• Newer features may accidentally break accessibility issues
  • Like any new features, we may introduce bugs unknowingly
  • Our accessibility audit team routinely inspect our product to improve quality
• Improving accessibility experiences
  • Although we are compliant, there are rooms to improve the experience
• Browsers occasionally breaks accessibility issues
  • E.g. Accessibility: screen reader repeat timestamp multiple times #3075 is related to https://bugs.chromium.org/p/chromium/issues/detail?id=1067257

There are few links here you may find your answers:

• https://docs.microsoft.com/en-us/compliance/regulatory/offering-WCAG-2-1
• https://www.microsoft.com/en-us/trust-center/compliance/accessibility

Please let us know if you can't find your answers in the links, we can loop a team member from our accessibility team to answer your questions.

[mgifford]

Thanks @corinagum @compulim for your feedback. This is great, both in it's speed and substance.

I missed the accessibility doc. I would suggest that you add something to the Readme, in particular encouraging feedback around ways to improve your accessibility. Having an open feedback loop is really important, as technology is constantly evolving. Think of it like security, you want to make sure that you are inviting users along on the journey to see that it is as good as can be.

In looking at the code that was produced I was disappointed to see that semantic HTML5 elements weren't being used as much as they could be in the interaction. There is a wide range of AT users and not everyone can process ARIA equally well, that said, all assistive technology can process HTML5.

It is also useful to learn about your testing process. Do you use axe or other tools to test for errors? Do you include manual testing as part of your agile process? This is something that is particularly useful to learn when there is a new release coming out.

Thanks again for your feedback.

[compulim]

Thanks @mgifford, ❤ your feedback.

Can you explain a little bit more about semantic HTML5 elements? Or may be a link to section in the WAI-ARIA guidelines/practices would be great, https://www.w3.org/TR/wai-aria-practices/. Or may be pointing out one issue and we can figure out the rest. 😉

Personally, I believe chat UI is a great companion for people with disabilities. Web design evolves so fast and can become complicated (look at https://webdesignclip.com/). Chatbot and chat UI could be a fast tool for web developers to make their websites inclusive. I mean, it's not a full cure, but I believe it could be a right direction, and I personally want to explore in this area.

TBH, we hit so many walls when handling accessibility issues. Our team has this mindset: if we can fix the accessibility issue by throwing away all the UI code, we are happy to throw away the code. We want a cure for accessibility issues, not a band-aid.

IMO, the core part of Web Chat is our test suite. As long as the new UI code can pass our existing tests, it should be good to ship. But sometimes, even throw away all the code doesn't cure the issue. And sometimes, we have to work across companies to resolve accessibility issues.

As I mentioned, we do have a comprehensive test suite. I would love to add Microsoft FastPass to the test suite. It is based on axe-core. I think it's beneficial for us to catch accessibility issues sooner. (Let me create a work item for us.)

Please continue to send your feedbacks and offer us advices. It is always great to hear feedbacks from inside and outside of Microsoft on how to make the world a better place. We really want to make our chat UI very accessible and loved by all people with or without disabilities.

p.s. the WAI-ARIA guideline is great for UI component developers, but it is lacking of guidelines for complex components like chat UI. And often aria-live="polite" is broken in some marginal scenarios which we hit many times.

[corinagum]

I made a PR for docs improvement: #3717

[mgifford]

@compulim I haven't done an exhaustive review, but seems that ARIA is being overused. Seems to be breaking the first rule of ARIA:

If you can use native HTML elements and attributes to communicate the proper semantics and behavior then do so. - https://www.w3.org/TR/using-aria/#rule1

Might also be useful to include a list of resources that have been reviewed on accessible chatbots including possibly links & comments on:

• https://a11y-guidelines.orange.com/en/web/components-examples/chatbot/
• https://www.canaxess.com.au/infocard/chatbots
• https://www.researchgate.net/publication/326042639_Accessibility_in_Chatbots_The_State_of_the_Art_in_Favor_of_Users_with_Visual_Impairment
• https://www.boia.org/blog/five-key-accessibility-considerations-for-chatbots

I've just scanned through those. You've probably got more.

This type of interaction isn't easy to build.

[corinagum]

@mgifford thanks for all the links; I appreciate looking through more material. Based on what you provided, I still feel good about Web Chat's accessibility design decisions.

If you stumble across specific examples of where we are underperforming or incorrectly using a11y features, please feel free to file a new issue pointing to what behavior / code that you find. Again, we very much appreciate your input, as well as any other customers who donate their time to look at our work.

I am closing this issue as a non-work item.

compulim recently merged in his latest accessibility work, which I am very excited about. I know he spent a lot of time on it, and customer feedback is welcome. The behavior is to navigate via aria-activedescendant the transcript for review. Very vital behavior. It is the following PR: #2996

If you would like to try it out, please check out our daily releases! This will be part of the R12 release, which is imminent.