Accessibility Issue - Article element declared inappropriately

[Bradrajkumar]

Issue Description : -

If a relationship between elements is expressed with visual cues, it also needs to be programmatically determinable. This enables assistive technology to communicate the relationships to users. Content may otherwise seem unstructured or disorganized.
There are article elements that are declared inappropriately. This does not convey a correct meaning semantically or structurally. This landmark is meant for independent or self-contained content such as individual blog posts, videos, images or news items.
This has been raised as an Additional Issue as WCAG AA does not require accurate page regions. It is required at WCAG AAA.

Success Criteria : -

Any relationship presented through visual cues must also confer that relationship through the appropriate semantics. Technically, article element is used to semantically mark the self-contained sections or compositions on a page. Remove the

elements from the chat messages.

Steps to reproduce

1. Observe the elements on the page.
2. Inspect the elements and review the DOM.
3. Observe the inappropriate use of.

Webchat Version :- 4.13.0

[compulim]

To DRI: In this reply, I gave explanation to our customer on some of the decisions we made. We still need to look at what they reply.

From your description, you mentioned article should only be used for blog posts, videos, images or news. In your DOM tree screenshot, the role="article" is highlighted. However, I believe you are not talking about this role, instead, you are talking about the <article> element one level up, which is the children of <section role="feed">.

Thus, in this reply, I am describing generally about how the article role is being used in the chat history, than that particular role="article" you highlighted, which is used for aria-activedescendant.

In our accessibility design document, we mentioned why we need to use <article> (or role="article") to identify a chat bubble. In additional to the document, let me put more information here. (I should roll it up back to the doc.)

In WAI-ARIA roles, there are not much roles that would fit for chat bubbles. There are:

• log role
• grid role
• feed role

log role

Excerpt from WAI-ARIA:

A type of live region where new information is added in meaningful order and old information may disappear. Examples include chat logs, messaging history, game log, or an error log.

While log role seems best fit for chatting (chat logs, game log), when we are using it in real world:

• Implicit live region
  • Due to bugs in screen readers, we have to use a separate live region, these bugs are not workaround-able
    • Adaptive Cards is a challenge because they emit a huge complex DOM tree, screen readers often misunderstand it in live regions
  • At the time we implement, some ATs will not turn off live region for log role
• Nested interactive content
  • log is good for static and simple content
    • A few sentences, images sparingly, but without audio clips, videos, inputs, or other widgets
  • Our chat bubbles could contain Adaptive Cards and other interactive widgets
  • log is not a complex widget, and interactive widgets inside log is not recommended because end-user do not expect non-complex widget to have nested interactive widgets
    • In other words, focus management and transcript navigation using log will create confusions

grid role

This is more like spreadsheet controls. One of our requirements is complex focus management and transcript navigation. As grid is a complex widget, it support nested interactive element and fit this requirement.

However, we believe grid is too generic and should only be used as the last resort.

feed role

This is for a scrollable list of articles. Few things we like it over other roles:

• feed support complex widget
  • article inside feed are expected to have interactive widgets, such as comment box
• feed could be used to present a stream of new stories, with text, links, images, and comments
  • This is actually what bot authors could present while using Adaptive Cards
• Support appending and prepending articles
  • In the future, we could support loading partial chat history, and end-user could scroll up to "load more". feed is designed to for this scenario
  • Particularly, it supports aria-setsize and aria-posinset, making navigation easy for users who uses AT
• feed has a very explicit and clear instructions on how to implement navigation for its complex widgets

While we understand "article" and "message" could be a bit confusing, we tried to use aria-roledescription to override that. However, when we test in Android and iOS, their support on aria-roledescription is limited-to-nothing. It actually made the experience worse. Thus, we could not use aria-roledescription.

Given all points above, we took some compromises and chose feed role instead of log role. As a requirement for feed role, all children must be article role. Thus, we use article role for the message.