Usability is Rooted in Semantics

Much if not most web content issues are due to a lack of proper semantic html code.

Why does it make a difference?

a. Because 20% of Web Users of A.T. / Screen Readers rely on semantics.

Fact is: the majority of accessibility bugs are from non-semantic html code, making it the bulk of work in a remediation plan by most digital web teams.

b. When proper code is missing, web traffic falls due to poor User Experience; and

c. Lawyers bring multi-million dollar law-suits for lack of equal access.

Question: 1. Does Content Structure Impact Usability and User Experience?

Answer: Yes, all digital web content is federally mandated to have heading structure to meet accessibility / usability compliance. This is a basic principle of accessibility.

Web pages are to follow a proper hierarchy of H1, H2, H3, etc.

The Kaiser main page lacks proper hierarchy using: H1, H1, H4, H4, then H2.

<h2 class="header-styles styling-3 --dolphin --light"></h2> (It appears the KP web team missed using an H2 for the below text, and left it empty above)

<p><span class="styling-4 --light"><span class="styling-2 --light">Specialty care the way it should be</span></span></p>

And there is no trace of an H3 while headers are mainly used for style and not for the intended semantic purpose of structure to provide a proper User Experience.

Other semantic issues on the KP & other web sites include:

A. Lacks Consistency of links and buttons;

Some links are styled as buttons and some buttons are styled as links which confuses users.

And believe it or not, sometimes the link is a button and the button is a link.

Same KP home page offers a hyperlink as both a button and then also as a link. Really, 2 different objects with the same role? Taking this liberty created two problems: lack of consistency and improper semantics.

ie: <button aria-label="Why choose Kaiser Permanente?" class="button mbl-link-button jkp_ee_ptl_cta_button" data-target="/content/kporg/en/national/why-kp" data-url="/why-kp" id="heroimage_button_heroimage" role="button">Why choose Kaiser Permanente?</button> (This is a hyperlink coded as a button)

And using the same text, the link is also offered as a proper href link, but the Dev Team felt it necessary to give it an id of: buttonlink. Even the KP Dev Team were confused by the mixed semantics and gave the href link a role of link. This semantic confusion is prevalent on many web sites, and labeling semantic html objects with an inherent role is redundant and a waste of time & bandwidth.

<a class="link mbl-only-link" href="/why-kp" id="heroimage_buttonlink" role="link" style="display: none;"> Why choose Kaiser Permanente? </a>

So, are these objects links or buttons? KP and other web teams think its okay to give them both the same role and to morph one object into another. This turns accessibility on its head.

These semantic inconsistencies compound accessibility issues and thwarts Usability.

Question: 2. Does Link Text Impact Usability?

Answer: Yes, User Cues need to be parsed with descriptive link text;

Some link text from the KP site conveys, "Read more", & other links convey, "Learn more";

These links are coded as links, but fail to offer the User a clearly parsed link description.

The best way to improve the web User Experience is to be consistent. KP and other sites are using <span> text to provide proper User cues, but only sparsely. Why? Because even in open space offices the web teams tend to work in silos with the right hand not knowing what the left hand is doing. This is clearly evident with the KP web teams by providing added User Cues to some objects as shown below, while failing to do so on their non-descriptive links. By inserting span tag text for Screen Reader Users as needed, all links, & all U.I. objects can be improved for better User Experience and accessibility through out a site:

<span id="timeout-modal-title" class="screenreader-only">Timeout Warning</span>.

All Digital Web Content Teams need to ensure proper semantics are provided in objects & text, and consistently with all digital web content.

Only mature web teams with better QA oversight are getting it right.

25% of non-compliant web content is prevented with proper semantics & web best practices;

Bad Semantics = Poor User Experience and lacks equal access

If implemented, Proper HTML Semantics are a win/win/win for KP and all web sites:

A. Save hundreds of hours of re-coding/ bug fixes for accessibility compliance;

B. Likely to increase web traffic and enhance your site's User Experience; and

C. Prevent law-suits for non-compliance and poor usability.

Ensuring Proper Semantics & Consistency in 3 Steps by S.Q.L. on the front end

• S = Tooling up with an accessibility web Scanner for full site coverage;
• Q = Providing governance for Quality assurance oversight to prevent gaps;
• L = Building a template code Library for consistency and a pipeline resource.

SQL on the front-end prevents web inconsistencies and improves accessibility and helps mature a Web program toward inclusive design, and equal access.