Open Web UI Design Specification for Enabling Automation (OUIA)

Development PatternFly-React
#1

Introduction

In Red Hat Management QE team we dedicate a lot of time to Web UI testing. As you might know Selenium is a common solution to automate browser actions. We created several abstractions around it to speed up tests development. But we think that it’s not enough. We would like to propose a specification of guidelines to follow when creating a new web framework or application.

OUIA

The goal is to ease the burden of individuals wishing to create and maintain automated testing environments.

The OUIA is composed of multiple sections. In this forum topic I would like to discuss guidelines for patternfly components such as Dropdown, Table, Alert and so on. In our terminology they are widgets, but let’s not focus on terminology and let me provide the key concept of OUIA:Widget

OUIA:Widget

This part is designed to cover widgets in use on pages. Widgets that are OUIA:Widget compliant
MUST have the following properties.

  • A root level HTML element with a data-ouia-widget-type attribute describing a unique name
    identifying ALL HTML widgets that can be controlled with the same code or interactions.

    • e.g. A page that has a special dropdown, could choose to name that dropdown as CustomDropdown.
      All instances of this CustomDropdown widget MUST be expected to be able to be controlled
      via the same automation.

  • An id attribute called data-ouia-widget-id which is OPTIONAL if there will only be
    one instance of the widget on the page at once. Any id on the page MUST be unique
    even if it is used by different widget.

    • e.g. A vertical navigation can be expected to only be instantiated once on a page, as such
      it does not need any other identifying factors. Another widget type, like a button, would be
      created multiple times on a page and requires some kind of value as a unique identifying id.

  • An attribute called data-ouia-safe which is True only when the widget is in a static state,
    i.e. no animations are occurring. At all other times, this value MUST be False.

We really would like to see it Patternfly and opened to any discussion about this proposal.

2 Likes
#2

thanks for writing this up @quarckster - @JennGiardino and @seanforyou23 - can you provide any input on whether or not this aligns or could possibly align with our accessibility initiatives?

#3

Some of the UI components do rely on the id attribute to enable certain accessibility features. So depending on the component, an id attribute might already be present.

This happens primarily in cases where we want to use contents defined somewhere in the dom as a label or description for something (i.e. aria-labelledby or aria-describedby), and to make that association, the contents must have an id. The other case that happens for some components is when we use the aria-controls attribute, which takes the id of the element being controlled (e.g. the tabs control the tab panel, buttons in the toolbar control the data view on the page, the hamburger controls the navigation, etc…).

#4

@JennGiardino @dgutride I did take a detailed look into the ARIA specification. This led me to actually consider something, what if we could use the accessibility toolkits to drive automation? So I went a fair distance down this path, trying out the python-atspi interface to see if I could get to information about the specific components on the page. Unfortunately not only was there an issue with something along the way, (I got an IndexError in Python), I realised that there are far too many differences between the different Accessibility toolkits across platforms and browsers to make this viable. It’s a real shame though, as it would have enabled complete abstraction of dropdown from any web interface, as long as they correctly responded to the accessibility toolkit.

I know that @dgutride, you were asking if we could reutilize existing roles or other attributes from ARIA. Looking more deeply into this, I don’t think this is possible. We need to specify with the OUIA which implementation of the component we are talking about, ie, is it Patternfly’s or Bootstrap’s or custom. The widget-type attribute would be important in distinguishing this. We are really hoping to push this out further than just PF, to other frameworks to create a standard that would enable consistent automation expectations if an application were to use OUIA. We would love to use it in a way that people don’t need to configure anything for the apps specific usage.

@JennGiardino As for the IDs. Though it is possible that there could be an “id”, we were hoping that having an explicit id set for automation could do two things. 1) Allow the developers to use the id field as they see fit, perhaps they are restricted in its usage by a JS framework or something and 2) Again to give a consistent id field that we know has been implemented for the purpose of UI automation. Something that people are less likely to change on a whim. The ID is something that I believe is not strictly Patternfly’s job to implement, but I could be wrong.

Are there any further questions regarding this?

1 Like