Terra-core: [terra-status-view] Accessibility issues with <div> usage

Created on 11 Oct 2019  路  6Comments  路  Source: cerner/terra-core

Bug Report

The status view title and message should use appropriate semantic HTML elements instead of divs to meet accessibility requirements. At the very least, the divs should be replaced with paragraph elements. Ideally, the status view title would be able to map to various header elements.

@ Mentions

@scottwilmarth @neilpfeiffer

terra-status-view bug

Most helpful comment

Amber Wilks and I chatted about whether this should be a < p > or < h# >. We both feel that a < p > would be a better option since the alert could happen at many levels. This would eliminate the need for a default value if teams don't understand the hierarchy of the page and ensure a better experience. On a higher level, the alert notification should convey the needed awareness and importance. While the heading levels may not be needed in this instance, in other areas the heading levels should be set by the hierarchy of the consuming page, not by the component itself.

All 6 comments

A quick note that if a header tag is used for the title, it should be implemented in such a way that the content on the final page dictates heading level based upon where the status view falls on the page. Hard coding a specific heading level into the status view may break the natural hierarchy of the page and, consequently, the accessibility of the page.

A quick note that if a header tag is used for the title, it should be implemented in such a way that the content on the final page dictates heading level based upon where the status view falls on the page. Hard coding a specific heading level into the status view may break the natural hierarchy of the page and, consequently, the accessibility of the page.

A solution is adding a prop that controls what heading renders. titleLevel perhaps.

A quick note that if a header tag is used for the title, it should be implemented in such a way that the content on the final page dictates heading level based upon where the status view falls on the page. Hard coding a specific heading level into the status view may break the natural hierarchy of the page and, consequently, the accessibility of the page.

A solution is adding a prop that controls what heading renders. titleLevel perhaps.

Agreed with @yuderekyu . If we are using an additional prop we need to have a default value if the user doesn't provide the prop.

@yuderekyu if we expect heading level for title should always be set by the consumer then we might have to make this new prop as required. and regarding the message should we use the paragraph elements ?

Amber Wilks and I chatted about whether this should be a < p > or < h# >. We both feel that a < p > would be a better option since the alert could happen at many levels. This would eliminate the need for a default value if teams don't understand the hierarchy of the page and ensure a better experience. On a higher level, the alert notification should convey the needed awareness and importance. While the heading levels may not be needed in this instance, in other areas the heading levels should be set by the hierarchy of the consuming page, not by the component itself.

Agreeing with @scottwilmarth -- I would prefer we not involve changing the title prop content to a heading element, but keep it and message as paragraph elements. The primary role of the status view is as content to describe/fill an empty page, not to serve as any kind of page hierarchy, which would be provided by an action-header or other similar header element to describe the page/panel/section.

Also since it is not the role of status-view to convey an alert or notification (handled by other UI elements), it is a much cleaner implementation to not ask consumers to set an appropriate h level within status-view.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

neilpfeiffer picture neilpfeiffer  路  3Comments

cwalten picture cwalten  路  6Comments

juliacalandro picture juliacalandro  路  3Comments

yuderekyu picture yuderekyu  路  3Comments

noahbenham picture noahbenham  路  4Comments