This blog post was originally published on Stefan Bauer’s blog under [Don’t use the improved title area in SharePoint] Don’t use the improved title area in SharePoint (n8d.at)

On September 3rd 2024, a new improved title area in SharePoint was announced. Sadly, this title area is two steps backwards in case of accessibility and readability of articles.

In short, you can now remove the title area completely or use it multiple times on a page. Both scenarios can harm your user, and here is why.

Accessible heading Structure

First, some basics on how articles on the web should be formatted in general, especially how to achieve optimal accessibility.

On every web page, there should be one main heading (h1), which should correlate with the page title. The rest of the page can use Heading 2 (h2) to the maximum of Heading 6 (h6).

Right now, every SharePoint page doesn’t use a main heading, not even in the title area.

It is also important that you have clear levels of headlines.
For example, on a heading level 2, a heading level 2 or headling level 3 can follow. There shouldn’t be a gap in those levels, for example, using “Heading 2” and as the next heading “Heading 3”.

How to build an accessible heading structure is explained by The A11Y Project in great detail.

Heading 1 in SharePoint

When in SharePoint, a new page got created, for example, using a “Visual Template”. One would assume the presented header is the main heading for the page or technically an h1.

Instead, the page title is a deeply nested structure of unspecific elements. So, the text only correlates with the overall page title but does not serve any semantic purpose. The header in SharePoint is purely decorative in a strict technical sense.

In SharePoint, it does not matter which template was chosen—all lack proper support for a main heading using a native H1 HTML element. It is like writing a Microsoft Word document without the title format template.

With a simple check for all the headings on the page, it simply returns an empty list without any heading visible or hidden.

The new options – removing the banner

As stated in the improved title area options announcement, they have considered accessible headers.

WCAG 2.1 Compliance:
How do you meet WCAG 2.1 criteria without a visible H1 title? If you opt not to have a title on the page, a hidden H1 element in HTML will ensure accessibility, with the H1 content derived from the page title on the command bar.Source: Improvements to the title area at the top of SharePoint Pages and News

When you remove the banner, you will suddenly get a heading level one. The following screenshot shows how the page looks without a banner.

The HTML on the page now can find one accessible header in the page’s code.

The now-present H1 element, of course, is hidden for you to see and only serves an accessibility purpose.

Adding the banner back removes Heading 1 again, and the “official banner” is just the deeply nested div structure.

Is it that bad?

Well, in the case of semantic page layout and accessibility, it is not optimal. The specification for Accessible Rich Internet Applications (WAI-ARIA) states in the “First rule of ARIA Use”:

If you can use a native HTML element [HTML51] or attribute with the semantics and behavior you require already built in instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.

Microsoft loves div elements, as no other HTML element would exist. In our case, the native HTML elements would be:

<h1>The main heading of a page</h1>
<h2>First regular heading in the content</h2>
<h3>Second regular heading in the content</h3>
<h4>Third regular heading in the content</h4>
<h5>Not used in SharePoint</h5>
<h6>Not used in SharePoint</h6>

HTMLCopy

You are safe in the case of headline hierarchy when two banners on a page exist, like in the following screenshot.

It uses the role=“heading” as well as the aria-level=“1” and aria-level=“2”. With the same effort used to define those additional attributes, a proper HTML markup would have been possible, too.

And as “Using role=heading to identify headings” states:

When possible, use native heading mark-up directly. For example, it is preferable to use h1 rather than using <div role="heading" aria-level="1">. However, the use of the heading role, instead of heading mark-up, may be necessary. For example, when retrofitting a legacy site where scripts depend on the existing element hierarchy.

So technically, it is correctly implemented, although I doubt it falls in the category “retrofitting a legacy site” and that scripts depend on it.

It is that bad

Especially for your users, it is that bad. Let’s take a look at the following example.

“Another heading” and “This is another H2” represent two different levels of the visual hierarchy. “Another heading” looks like the main heading of a page. The right accessibility was applied to the element. People who don’t rely on assistive technologies might be disturbed by the sudden “Page Heading”.

“This is another H2” is a heading level two, like the “Another heading”. In this situation, they look different, but their meaning is completely visually different.

“Another Heading” is the heading of an empty content area—a headline for nothing. Intranet authors can use this but always need to choose “Heading 3” to craft accessible sites.

Another bad example was listed in Microsoft’s blog post too.

With a banner in a full-width section and three banners below in an overlap configuration, all four pieces have the same visual hierarchy and cannot be differentiated. The same heading and accessibility problem happen here, too. This time on purpose.

All banner headings have the same hierarchy. The headlines are headings level 2, while the more appropriate setup for these headlines would be an H2 on top followed by H3. Yet here, it becomes tricky. How does one webpart, or end user, know what the correct markup would look like? It can’t unless they are somehow connected and referenced by each other. This setup is not easy for the end user to achieve.

Conclusion

Should you use the new and improved banner web part? The short answer to this is no, except on the top of the page. In any other case, it can cause distraction and confusion. Not only end-users but also confuses blind people with low vision.

Of course, it would be nice to have more flexibility in SharePoint and have many of the features that have been demonstrated. Accessibility and usability should always be the top priority of those features.

Almost four years ago, I did a design review on the typography of SharePoint pages and the typography . In this blog post, I pointed out that SharePoint needs an optimal design regarding readability. Since then, nothing has improved, and it remains as it has always been.

With features like the improved banner, readability becomes even worse.

About the Author:

Stefan Bauer

I love to bring beautiful, sustainable, flexible designs based on solid technologies to life. Driven by curiosity, he tries to find new innovative ways to solve aesthetic and functional problems.

After several years in the web design and technology industry and working with international agencies and customers, i founded the design studio named N8D. This brand, first established in 2010, served since then as his website and blog. The same website and Microsoft community collaboration led to multiple Microsoft Most Valuable Professional award recognitions since 2016.

Reference:

Bauer, S (2024). Don’t use the improved title area in SharePoint. Available at: Don’t use the improved title area in SharePoint (n8d.at) [Accessed: 26th September 2024].