Accessibility Tree for keyboard and screen reader support

[linkdotnet]

What is an accessibility tree?

The Accessibility Tree indicates what information the page provides to assistive technology such as screen readers.

The Accessibility Tree is a subset of the DOM tree, which contains elements from the DOM tree that are relevant and useful for displaying the contents of a page in a screen reader.

^Source

Basically a new representation of the DOM with a focus on accessibility. The idea would be to add such a tree with a new function GetAccessibilityTree to make it easier for users to traverse this tree.

Motivation

The motivation stems from the fact that we want to make it easier for a user to have the representation. Furthermore adaptive technologies will become more prominent in the future. Users might want to have such requirements tested with a dedicated set of APIs.

Why does it need a new function instead of using cut.Find().GetAttributes?

1. Easier to traverse if we have our own representation and don't mix multiple things.
2. Filtering irrelevant stuff and concentrating on one thing at a time (Encapsulation and easier maintenance for us)
3. Giving the user a centralized way of doing all this.

Implemenation

We would sit on top of either IElement or IRenderComponent (where this would just get the INodeList and pass it to the former one).

public static AccessibilityNode GetAccessibilityTree(this IElement rootElement)
{
    // Create the root node of the accessibility tree
    var rootNode = CreateAccessibilityNode(rootElement);

    // Recursively build the accessibility tree
    BuildAccessibilityTree(rootNode, rootElement);

    return rootNode;
}

private static void BuildAccessibilityTree(AccessibilityNode parentNode, IElement parentElement)
{
    // Iterate through the child elements of the parentElement
    foreach (IElement childElement in parentElement.Children)
    {
        // Create an AccessibilityNode for the child element
        var childNode = CreateAccessibilityNode(childElement);

        // Add the child node to the parent node's children collection
        parentNode.Children.Add(childNode);

        // Recursively build the accessibility tree for the child node and element
        BuildAccessibilityTree(childNode, childElement);
    }
}

private static AccessibilityNode CreateAccessibilityNode(IElement element)
{
    // Extract relevant accessibility attributes from the element
    var role = element.GetAttribute("role");
    var ariaLabel = element.GetAttribute("aria-label");
    var ariaDescribedBy = element.GetAttribute("aria-describedby");
    // ... 

    var node = new AccessibilityNode(role, ariaLabel, ariaDescribedBy, /* ... other attributes ... */);

    return node;
}

Accessbility node could have properties like (not sure if they are complete :D):

• Role
• AriaLabel
• AriaDescribedBy
• AriaHidden
• AriaExpanded
• AriaSelected

Alone with that, the user might have a model (s)he can work with. We could provide further API's to make it easier:

public static AccessibilityNode[] FindNodesByRole(this IElement elem, string role) { ... }
public static AccessibilityNode[] FindNodesByLabel(this IElement elem, string label) { ... }
...

Considerations

Probably that doesn't have to be built in bunit per-sé. It could be an extension package for Anglesharp, or it could sit on top of IRenderComponent. So it doesn't have to run directly under the "bUnit" brand if you want to say so.

[egil]

Just glanced over this. It seems very related to the "testing library" API we are considering.

[linkdotnet]

It is partially related with a small overlap.
I checked again the issue tracker and the linked page and it doesn’t say much about accessibility.

One could go so far as to check for WCAG standards with an easy API that reports all violations.
I am not saying we want this ;) (Probably also not so easy for stuff that is related to CSS / JS)

[egil]

Testing Library is implicitly about accessibility. When we perform a FindByRole("button"), it doesn't only elements with role=button, it also finds button elements. Then there is https://testing-library.com/docs/user-event/intro, which could be something we could look into as well. So that's why I see overlaps.

Anyway, I also think this may actually be something that should exists over in AngleSharp, and not in bUnit. You may want to suggest it over there. I'm pretty sure @FlorianRappl would be interested too.

[linkdotnet]

Oh that's fair - it was an idea I eyeballed with and I was almost certain it doesn't belong directly into bUnit, but more in an extension - or, as you said, in Anglesharp itself.