TPGi conducted a Web Accessibility Review for Duke Energy Manual Audit on December 09, 2021 - January 31, 2022 at the request of Duke Energy to determine if it is possible for users who have visual disabilities and who use a screen reader to access the content and perform key functions on the website.

Engagement Details

Title: Duke Energy Manual Audit

Engagement Type: Responsive Web Accessibility Review

Standards: WCAG 2.1

Environment: Responsive Web

Assistive Technologies: Firefox and NVDA, Safari and VoiceOver, Chrome and JAWS

Testing Tools: ARC Toolkit, Colour Contrast Analyser, ARC Capture Extension

Variant Schemas: Chrome - Desktop

Technologies: HTML, CSS, ARIA, JavaScript

User Journeys and Components Reviewed:

A. Common Components

1. Secondary Nav - https://scjsstest.duke-energy.com/home

2. Footer - https://scjsstest.duke-energy.com/home

3. Footer - https://scjsstest.duke-energy.com/home

4. Primary Nav - https://scjsstest.duke-energy.com/home

5. Common Issues - https://scjsstest.duke-energy.com/home

B. Component Library

1. Video Player - https://scjsstest.duke-energy.com/home/products/power-manager

2. News and Resources - https://scjsstest.duke-energy.com/Our-Company/About-Us/Power-Plants/Asheville-Plant

3. Table - https://scjsstest.duke-energy.com/home/billing/billing-payment-options

4. Multi Video - https://scjsstest.duke-energy.com/our-company/careers/benefits

5. Push Down Panel - https://scjsstest.duke-energy.com/home/billing/paperless

6. Flipboard - https://scjsstest.duke-energy.com/our-company/about-us

7. Tab - https://scjsstest.duke-energy.com/home/products/renewable-energy/nc-shared-solar

8. Hero Stock Chart - https://scjsstest.duke-energy.com/our-company

9. Accordion (FAQ) - https://scjsstest.duke-energy.com/home/billing/paperless

11. More Info - https://scjsstest.duke-energy.com/home-services

C. Feedback

1. Your Feedback Aside - https://scjsstest.duke-energy.com/home

2. Feedback - https://scjsstest.duke-energy.com/home

D. Form

1. Form - https://scjsstest.duke-energy.com/home-services/gas-line-repair/enroll

2. Multi Step Form - https://scjsstest.duke-energy.com/business/products/design-assistance/request

3. Date Picker - https://scjsstest.duke-energy.com/business/products/design-assistance/request?first_name=test&last_name=test&company=sdsd&title=sds&Company_Role__c=Account+Executive&street=test&city=test&zip=08844&EDA_Project_Name__c=sdd&email=tes%40test.com&emailconf_predef=tes%40test.com&phone=9089639922&EDA_Anticipated_Permit_Date__c=&EDA_Schematic_Design_Date__c=&EDA_Design_Development_Date__c=&EDA_Construction_Documents_Date__c=&EDA_Construction_Completion_Date__c=&Building_Square_Footage__c=&Parking_Garage_Sq_Ft__c=&Data_Center_Sq_Ft__c=&Above_Grade_Stories__c=&Below_Grade_Stories__c=&Percent_Cooled__c=&Other_energy_design_alternatives__c=&Special_considerations_and_other_comment__c=

E. Global Alert

1. Global Alert - https://sctest.duke-energy.com/home/healthcheck

F. Home

1. Product Cards - https://scjsstest.duke-energy.com/home

2. Jurisdiction Selector - https://scjsstest.duke-energy.com/home

3. Search - https://scjsstest.duke-energy.com/home

4. SignIn - https://scjsstest.duke-energy.com/search-results?searchInput=undefined

5. Nav Cards - https://scjsstest.duke-energy.com/home

6. News Banner - https://scjsstest.duke-energy.com/home

7. Top tasks - https://scjsstest.duke-energy.com/home

G. New Components

1. Quick Links - https://scjsstest.duke-energy.com/home/products/outdoor-lighting#?type=fixtures&style=Sanibel%20LED

2. Modal - https://scjsstest.duke-energy.com/home/products/renewable-energy/nc-solar-rebates

3. Call to action - https://scjsstest.duke-energy.com/home/products/renewable-energy/nc-solar-rebates

4. Bulleted Overview - https://scjsstest.duke-energy.com/our-company/about-us

5. Twitter - https://scjsstest.duke-energy.com/our-company

6. Photo with Caption - https://scjsstest.duke-energy.com/our-company/about-us/leadership/lynn-j-good

7. Email Signup - https://scjsstest.duke-energy.com/home

8. Jurisdiction Intercept - https://scjsstest.duke-energy.com/home/billing

H. Pay My Bill

1. Rectangular Card - https://scjsstest.duke-energy.com/home/billing

2. Centered Card - https://scjsstest.duke-energy.com/home/billing

I. Search

1. Search Results Page - https://scjsstest.duke-energy.com/search-results?searchInput=the

Findings

Screen reader users will have a difficult time fully understanding the content and performing some functions.

The following top key issues specific to the Duke Energy Manual Audit will make it difficult for screen reader users:

Duke Energy's test site presents considerable challenges for people with visual and motor disabilities that use assistive technologies.

There are significant accessibility issues in the site's template components, which appear on almost every site page. The site makes wide use of side panels to sign into the site, search the site, register one's email, and provide feedback.

These side panels have the behavior of dialogs, but lack all required focus management techniques. When these panels appear, focus is not set to the panel's container or a focusable element within the panel. As a result, screen reader users are not aware that the panel has appeared. In most cases, the panel represents the last element in the page's markup. Assistive technology users must navigate through the entirety of page content to reach these panels.

When the panels are visually hidden, they are positioned offscreen but remain accessible to screen readers and to users that navigate the page using the TAB key. As a result, when a keyboard user tabs onto the elements within these panels, it is not possible to visually determine what element is currently focused.

The site makes wide use of decorative icons and images to augment the visible text. The visible text, by itself, is sufficient for screen reader users to understand the purpose and meaning of the content. These decorative elements do not convey meaningful information, yet they frequently have redundant, unnecessary text alternatives. These text alternatives increase the page noise, making site navigation more cumbersome for screen reader users.

Despite the barriers present in the site's template components, a number of accessibility features are well-implemented. The site has a skip link to bypass the navigation region and jump to the main content region. The site's videos have closed captioning, ensuring that people that are deaf or hard of hearing can have the same experience as those able to fully hear the videos. Most site controls are keyboard accessible; a sighted, keyboard user should be able to access most of the site's core functionality. The site consistently has a visual focus indicator; however, given that the site uses the browsers' default focus outline, the visual focus indicator may at times, be hard for low vision and color-blind people, to perceive.

User Journey and Component Findings

This section of the report documents the accessibility findings that impact screen reader users, as well as recommended changes. The Web Accessibility Review included 48 components across 9 user journeys to determine what the user experience would be for a screen reader user.

Summary of Priority Findings by WCAG 2.1 Success Criteria

WCAG 2.1 Success Criteria

Checkpoint

Level

Failure Count

1.1.1 Non-text Content

1.2.5 Audio Description (Prerecorded)

1.3.1 Info and Relationships

1.3.2 Meaningful Sequence

1.3.5 Identify Input Purpose

1.4.10 Reflow

1.4.11 Non-text Contrast

1.4.12 Text Spacing

1.4.3 Contrast (Minimum)

1.4.4 Resize text

1.4.5 Images of Text

2.1.1 Keyboard

2.4.3 Focus Order

2.4.4 Link Purpose (In Context)

2.4.6 Headings and Labels

2.4.7 Focus Visible

2.5.3 Label in Name

3.1.2 Language of Parts

3.3.1 Error Identification

3.3.2 Labels or Instructions

3.3.3 Error Suggestion

4.1.1 Parsing

4.1.2 Name, Role, Value

4.1.3 Status Messages

Total Issues

269

NOTE: In addition, 13 Best Practice issues have been documented. While these are not failures of WCAG criteria, their implementation would improve the accessibility and usability of the user interface.

Explanation of Table Headers

1. # - A unique issue number for cross-referencing throughout the report.

2. Issue Description - Description of where the page is not consistent with the specified accessibility standards.

3. Modification - Suggestions for fixing the problem.

4. STD (Standard) - The three-part numbers (e.g. 1.1.1) refer to the WCAG 2.1 success criteria (http://www.w3.org/TR/WCAG21/).

5. Count - Number of issues found.

6. PRIO (Priority) - The priority column indicates the recommended order in which the issues are remediated.

a. 1 are recommended to be remediated first. These issues will block access for a screen reader user or would make the content very difficult to understand.

b. 2 is the next most important issue to be fixed. These issues are areas where a screen reader user will have a difficult time interacting with the site and understanding the content.

c. 3 are a bit less 1 than the issues marked priority 1 and 2 and should be fixed after the issues identified as P1 and P2 are fixed.

NOTE: The priority of an issue provides a guide to remediation priority only and is not necessarily the same as the A, AA, and AAA conformance levels of the WCAG success criteria related to the issue. Unless indicated otherwise, all issues listed in the report require remediation to fix the critical and high priority WCAG 2.1 conformance issues on these key screens and other similar pages that we did not review.

User Journey: Common Components

1. Secondary Nav

Secondary Nav Technical Details

Issue Description

Modification

STD

Count

PRIO

1.1

Landmark use is incomplete or incorrect

When a page has multiple <nav> elements, each must be given a unique label. The <nav> element for the site's secondary navigation lacks a label to identify its purpose.

The container for each expandable menu is marked up as a <nav>. This results in a <nav> containing a <nav>.

Recommendation

When using landmarks on a web page, ensure they are used correctly:

Apply a unique label to the <nav> containing the set of expandable menu widgets. Remove the aria-label="Site" attribute from the <nav>'s parent <div> and instead apply it to directly to the <nav>.
Remove the <nav> role from the container for each expandable menu.

Simplified, recommended markup for an expandable menu

<div> <nav aria-label="Secondary navigation"> <ul> ...

</ul> </nav> </div>

Assistive technologies typically ignore the aria-label attribute when it is applied to generic elements such as a <div> or a <span>. This is noted in a separate best practices assertion.

Resources

1.3.1 Info and Relationships A

1.2

ARIA attribute applied to generic element

Not all ARIA role combinations are valid. When ARIA attributes conflict with the underlying semantics of an element, it may cause at best, have no effect or at worst, cause unpredictable behavior for assistive technologies.

aria-label is primarily designed to provide an accessible name to an element. aria-label, aria-labelledby, aria-describedby are generally ignored by assistive technologies when they are applied to generic HTML elements that do not provide any meaningful semantic information i.e. <div>, <span>.

The <div> container for the set of expandable flyout menus (My Account, Billing & Payments, Products & Services, Start, Stop, & Move, Outages, Customer Service) has an aria-label="Site" attribute.
The <div> container for each expandable menu has an aria-label="Submenu" attribute.

In both cases, the direct descendant of the <div> is a <nav>.

Recommendation

Remove the aria-label attribute from each <div> container. Instead apply the aria-label attribute to its descendant <nav>.

Simplified, recommended markup for expandable "flyout" menu

<div>

<nav aria-label="Submenu"></nav>

</div>

Note:

To determine whether a role and aria-* is invalid, consult the W3C Document conformance requirements for use of ARIA attributes in HTML.

Resources

1.3

Consecutive links with the same destination

When there are consecutive links with the same destination but have different link names, it is confusing for screen reader users and makes site navigation less efficient.

The logo-based "Duke Energy" link and the next element, the "For Your Home" link have the same destination.

Recommendation

The "For Your Home" link is repetitive and does not clearly visually indicate that it is a link. It is suggested to remove link markup from "For Your Home". This will make site navigation more efficient for assistive technology and keyboard-only users.

User testing and reviewing site analytics is recommended to determine the change is preferable to users.

2. Footer

Footer Technical Details

Issue Description

Modification

STD

Count

PRIO

2.1

Images of text are used

Images of text can be problematic for users with low vision, color blindness, and cognitive impairments. When text is presented as an image, it is not possible for users to change the presentation of the text to suit their particular needs and preferences (such as changing the font/typeface, changing the foreground/background color to increase contrast, increasing line height or spacing).

In addition, when text is presented using bitmap images (JPEG, PNG, GIF), it generally becomes blocky, blurry and harder to read for users that use browser zoom or magnification software.

The "Building a Smarter Energy Future" text is an image of text and not HTML text.

Recommendation

Authors are encouraged to use "real" text in their web pages rather than making images of text (<img> elements, CSS background images, rendered dynamically on <canvas> elements, SVG path data, etc.), unless the particular way in which text is visually presented is essential and/or cannot be achieved using regular technologies like HTML/SVG/CSS (including, but not limited to, the use of text-shadow, web fonts, gradient backgrounds, rounded corners).

For "Building a Smarter Energy Future", the styling is not tied to branding such as a logo. The text is feasible to recreate using HTML and CSS. Therefore, it is recommended to use real HTML.

1.4.5 Images of Text AA

2.2

Nested footer landmarks

The <footer> has a direct descendant <footer> element. It is inappropriate to have a footer within a footer. This duplicative use of the footer landmark may cause confuse for screen reader users that make use of landmark navigation.

Recommendation

Do not nest <footer> or elements with role="contentinfo" within <footer>.

Remove either the parent or child element that is conveying footer landmark semantics.

Simplified recommended markup for footer landmark

<footer> <!-- remove the nested footer

<footer role="contentinfo"> ... </footer> --> <footer>

Resources

1.3.1 Info and Relationships A

2.3

A color contrast ratio of 3:1 is not provided for graphical objects used in controls

In Firefox, The "@ Sign up for Email" button uses the browser's default focus indicator, which has insufficient color contrast with the footer background.

Focus indicator: #0060DF Background: #005984 Contrast ratio: 1.4:1

Recommendation

Provide enough contrast between the foreground color and background color (or, more generally, "adjacent" colors that need to be distinguishable in order to correctly perceive/understand the graphical elements or their component parts) so that people who are color-blind or with moderately low vision can sufficiently distinguish important content. The contrast ratio must be at least 3:1.

The browser's default indicator is exempt from the WCAG Non-text Contrast (Level AA) Success Criterion 1.4.11 when the adjacent colors are also the browser's default styling. The footer background is not the browser's default styling. Therefore, the Success Criterion applies to the button.

1.4.11 Non-text Contrast AA

2.4

Decorative images are not hidden from screen reader users

The iOS and Android badges are image-based links. For each link, the <a href> container has an aria-label attribute which provides the control's accessible name. Each link's descendant image has an alt attribute to also provide a text presentation. Given the aria-label attribute, the descendant image can be considered decorative; its alt attribute is unnecessary.

Recommendation

Use an empty string as text alternative alt="" for each badge link. This will ensure that the image is not announced by assistive technologies. When an image is indicated as decorative through the alt="" attribute, there's no possible benefit to doubling-up with the aria-hidden attribute. Remove the unnecessary aria-hidden attribute from the <img>.

Recommended (simplified) markup for decorative image

<a href="https://itunes.apple.com/us/app/duke-energy/id1325217974?mt=8" target="_blank" aria-label="Download on the App Store" >

<img alt="" src="...">

</a>

Resources

Text alternatives for images

1.1.1 Non-text Content A

3. Footer

Footer Technical Details

Issue Description

Modification

STD

Count

PRIO

No issues identified.

4. Primary Nav

Primary Nav Technical Details

Issue Description

Modification

STD

Count

PRIO

4.1

Large scale text does not have a 3:1 color contrast ratio

Large size text does not have sufficient contrast with its background. This means people with moderately low vision or color blindness will have problems reading the text.

In the expandable side navigation menu, the buttons, when in hover state, lack sufficient color contrast between the background and the button text.

Foreground: #E0F6FB Background: #00789E Contrast ratio: 1.3:1

Recommendation

Provide enough contrast between the foreground (text) color and background color so that people who are color-blind or with moderately low vision can read text and distinguish elements. For large text (at least 18pt / 24px, or bold and at least 14pt / 18.5px), the contrast ratio must be at least 3:1.

1.4.3 Contrast (Minimum) AA

4.2

Changes in language are not explicitly marked up

To identify any changes in language - when certain content is in a language that's different from the overall language defined for the page - include the lang attribute on the most appropriate container/element, and set it to the value of the appropriate language code.

When the site is set to English, the button to switch to Spanish reads "Español". The button lacks a lang attribute to specify that it is a different language than the page's primary language.

When the page is toggled to Spanish, the test environment remains in English. The select language button's text changing to "English". The test site does not have a Spanish version.

Note: In the production site, when the site is presented in Spanish, the <html>'s lang attribute shifts to lang="es-US" to specify the page is in (US) Spanish. The "English" button (to shift back to English version) lacks a lang="en" attribute to specify that it is a different language than the page's primary language, Spanish. Production site is out of scope for this audit.

Recommendation

The lang attribute must also be used to identify chunks of text in a language that is different from the document's primary language.

When the page is in English, apply lang="es" to the button with name, "Español".

Adding lang="..." attribute with appropriate language code

<html lang="en"> <body> ... <button lang="es">Español</button> <button>Sign In</button> </body> </html>

When the page is in Spanish, apply lang="en" to the button with name, "English".

Adding lang="..." attribute with appropriate language code

<html lang="es-US"> <body> ... <button lang="en">English</button> <button>Iniciar sesión</button> </body> </html>

3.1.2 Language of Parts AA

4.3

The menu button does not follow the established design pattern

A menu button is a type of button which is used to trigger a pop-up menu, but must convey this functionality to assistive technology. The menu buttons found are missing the appropriate ARIA attributes and are not identified as menu buttons.

The "hamburger menu" button, which opens the side navigation panel, lacks the ARIA attributes to indicate that it opens a pop-up.

Note:

When the navigation menu button is activated, the side navigation panel opens in the behavior of a dialog. Focus remains on the button and does not move to the navigation menu. This lack of focus management is reported in a separate 2.4.3 assertion.

Recommendation

Ensure that the <button> element that triggers a pop-up menu has an aria-haspopup="true" attribute to indicate to assistive technologies that the button has an associated menu.

Simplified, recommended markup for navigation menu button

<button aria-label="Navigation menu"

aria-haspopup="true"_

</button>

Resources

WAI-ARIA Authoring Practices - Menu Button

4.1.2 Name, Role, Value A

4.4

Label is not sufficiently descriptive

Labels which do not sufficiently describe the functionality of an interactive control, such as buttons and form controls, make it difficult for users to understand the purpose of the control.

The hamburger menu button, which opens the side navigation panel, derives its accessible name from its aria-label="menu" attribute. The name does not indicate the menu's primary purpose.

Recommendation

The visible text, or alternative text, used to label interactive elements must clearly and concisely describe the control's function or purpose.

Revise the aria-label attribute to be more descriptive of the button's purpose e.g. note which menu is being opened. "Open full site navigation" is suggested.

Simplified, recommended markup for the hamburger menu button

<button aria-label="Open full site navigation"

aria-haspopup="true"_>

</button>

Resources

WCAG Technique: Providing descriptive labels

2.4.6 Headings and Labels AA

4.5

Side navigation panel lacks the focus management required for a dialog

The side navigation panel has the behavior of a dialog. The side navigation menu appears above a dimmed overlay covering the main page content. The interaction lacks the necessary focus management.

When the side navigation menu opens, focus remains on the hamburger menu button and does not move to the side navigation menu.

Focus is not constrained to the side navigation menu. A keyboard user is able to tab to focusable elements visually positioned under the dimmed overlay. As a result, it is not possible to determine what element is currently focused.

Inversely, when the side navigation menu is closed, focus does not return to the hamburger menu button, which triggered the menu to open.

Neither the dialog nor a descendant of the dialog programmatically receives focus when the dialog is invoked. This results in a screen reader user being unaware that the dialog has rendered on screen.

Recommendation

When the side navigation menu is launched, focus must be moved to the menu. The safest option for keyboard and assistive technology users is to treat the navigation menu like a dialog and use the focus management techniques required for dialogs.

Set initial focus

Apply role="dialog" to the <div> container for the navigation menu. Then set focus to this element with role="dialog". To achieve this, make sure that the <div> element with role="dialog" can be programmatically focused (with the JavaScript focus() method) by setting tabindex="-1" on the element.

When the dialog is closed, return focus to the hamburger menu button which triggered the navigation menu to open.

Focus management within the menu

The dialog containing the navigation menu should "contain" focus. Navigating via the TAB key should cycle through the focusable controls in the dialog until the user either closes the menu (by activating the "Close" button or pressing the ESC key.

2.4.3 Focus Order A

4.6

Side navigation does not follow established pattern for dialogs

The side navigation panel has the behavior of a dialog, but lacks all of the necessary semantics.

Container for side navigation lacks role="dialog" to indicate that it is a dialog.
When the side navigation panel opens, focus remains on the hamburger menu button and does not move to the side navigation. As a result, screen reader users are unaware that the content has appeared.
Content in the background is still announced by and reachable to assistive technology while the modal dialog is showing.

Recommendation

Add the role dialog to the element containing the side navigation menu and the close button.
For dialogs with a visible title, use an aria-labelledby reference to the element containing the title text (ideally an <h2>) to provide an accessible name. For dialogs without a visible title, use aria-label to provide an accessible name. The side navigation does not currently have an element that functions as a title. Therefore, apply aria-label to the element with role="dialog".
Set focus to the element with role="dialog" or to the <nav> within the dialog. Apply tabindex="-1" to the element serving as the focus target. This is further discussed in a separate 2.4.3 assertion.
Ensure that keyboard focus is constrained to the modal dialog until it is dismissed.
Ensure that the content obscured by the modal dialog is properly hidden from assistive technologies. Apply aria-hidden="true" to the inactive page content behind the dialog. This hides it from the reading order as perceived by assistive technology, while allowing it to remain slightly visible behind the dialog. Be sure to remove the aria-hidden attribute from page content when the dialog is closed.
The side navigation currently has a close button. It is suggest to add functionality where pressing ESC key dismisses the dialog and returns focus to the hamburger menu button.

Simplified, recommended markup for side navigation dialog

<html> <body> <div class="dimmed-overlay" aria-hidden="true"> <main> ... </main> </div> <div role="dialog" aria-label="Navigation panel"> <nav aria-label="Main navigation" tabindex="-1"> ... </nav> </div> </body> </html>

Resources

4.1.2 Name, Role, Value A

4.7

Side navigation panels lacks focus management between menu and submenu levels

The side navigation is a horizontally sliding set of menu/submenus. There is a lack of focus management in navigation between the main menu and the submenus.

When an element containing a submenu, such as "My Account", is selected, the content within the side navigation panel horizontally slides offscreen to display that submenu. However, focus does not move to the start of the new content. Focus remains on the control which triggered the new content, but the control is removed from the page and there is a loss of keyboard focus. As a result, screen reader users are not aware that new content has appeared.

Recommendation

Ensure that when a submenu is selected, focus is set to a logical target within the new content and that it triggers a meaningful announcement to assistive technology.

From one level of navigation to the next level, there are multiple acceptable focus targets. Either set focus to the navigation link to move back up a level or to the first link within the submenu. For example, in the main navigation menu, when "My Account" is activated, set focus to either the "Main Menu" link or the "My Account" link. If the user selects to move back to the "Main Menu", set focus to the "For Your Home" heading.

Note:

The site's side navigation panel does not use the ARIA menu pattern. This assertion uses the terms "menu" and "submenu" for the sake of simplicity. It is a good decision to not use the ARIA menu pattern and the use of these terms should not be interpreted as encouraging use of the ARIA menu pattern in this context. The menu pattern is intended for desktop-like applications and is inappropriate for a site's navigation.

2.4.3 Focus Order A

4.8

ARIA attribute applied to generic element

Not all ARIA-role combinations are valid. When ARIA attributes conflict with the underlying semantics of an element, it may cause at best, have no effect or at worst, cause unpredictable behavior for assistive technologies.

aria-label is primarily designed to provide an accessible name to an interactive element or elements that act as landmarks. aria-label, aria-labelledby, aria-describedby are generally ignored by assistive technologies when they are applied to generic HTML elements which do not have an interactive role e.g. button, link, input.

The <div> container for the side navigational panel has aria-label="Side panel" attribute

Recommendation

The side navigation panel lacks the dialog role attributes. Remove the aria-label="Side panel" attribute from the <div> within the <nav>.

Note:

To determine whether a role and aria-* is invalid, consult the W3C Document conformance requirements for use of ARIA attributes in HTML.

Resources

W3C Document conformance requirements for use of ARIA attributes in HTML

5. Footer

Footer Technical Details

Issue Description

Modification

STD

Count

PRIO

No issues identified.

6. Common Issues

Common Issues Technical Details

Issue Description

Modification

STD

Count

PRIO

No issues identified.

User Journey: Component Library

7. Video Player

Video Player Technical Details

Issue Description

Modification

STD

Count

PRIO

7.1

An audio description is not provided

The video includes visual content that is important to the meaning and understanding of the video but it is not provided via audio description. Blind and low vision users will not be able to understand the content.

Recommendation

Provide an audio description of all meaningful visual aspects of the synchronized media presentation.

An audio description is a specifically made audio track which, in addition to the regular audio elements of the media presentation, describes any meaningful visual aspects of the synchronized media presentation - this includes visible text, key visual elements such as graphics superimposed over a video (e.g. an arrow pointing to a UI element or a box around a group of UI elements), actions taking place in a video, or animations in an animated SVG diagram. This can be provided in various forms, ranging from an alternative audio track that a user can enable, a separate video file (in the case of a self-contained audio/video presentation), or a completely separate page with the synchronized media presentation which incorporates the audio description.

For a good example of audio description, see YouTube: MSFTEnable - Introduction to Disability and Accessibility (audio described version), which includes audio description in the natural pauses of the regular narration track in the segments between 3:26 and 11:10.

If the original presentation does not provide sufficient natural pauses, a possible approach is to provide extended audio descriptions. With this approach, playback is paused while the audio description plays, and resumes when the description has ended. An example of this approach can be found in the CaptionSync Smart Player.

You may also keep this video as it is and provide a link to the same video with audio description. The link to the audio-described video must be adjacent to the original video and must not be difficult to find.

Remediating this assertion will also resolve violations for the following success criterion: 1.2.3: Audio Description or Media Alternative (Prerecorded).

1.2.5 Audio Description (Prerecorded) AA

7.2

Video requires both horizontal and vertical scrolling when resized to a width of 320 CSS px / height of 256 CSS px

In smaller viewports or when zoomed in, content requires scrolling in two dimensions. Users with low vision will find it difficult to read and understand content.

Recommendation

Ensure that all content adapts and reflows to a viewport width of 320 CSS pixels without loss of information or functionality, and without requiring both horizontal and vertical scrolling. An exception is content which requires two-dimensional layout for usage or meaning, such as data tables.

To ensure content does not cause horizontal scrollbars or end up clipped, do not use large fixed-width elements. Use CSS techniques such as relative units of measurement, flexbox layout, and/or media queries to display all content while achieving appropriate styling in small and large screens.

Example of using relative units of measurement for a primary content area

.content { width: 90%; }

Example of using media queries for more specific styles

<link rel="stylesheet" href="basic.css"> <link rel="stylesheet" media="(max-width:320px)" href="small.css"> <link rel="stylesheet" media="(max-width:600px)" href="medium.css"> <link rel="stylesheet" media="(min-width:601px)" href="large.css">

Note: CSS techniques like these achieve responsive web design goals while allowing desktop browser users to zoom in to 400%.

Resources

1.4.10 Reflow AA

7.3

Third party content is not accessible

Web authors are responsible for ensuring that all third party content is accessible, including:

content that is part of a service supplied by an external provider, such as ecommerce processes, online booking systems, product shipping tracking, and standalone user login systems.
content in the form of media supplied by an external provider, such as embedded videos from providers like YouTube and Vimeo, commercial news feeds, social media feeds, online entertainment feeds, games, tickers, and advertisements.
content supplied or generated by users, such as blog posts, comments, articles, images, and videos uploaded by users.

The video is an embedded YouTube video and has several accessibility issues, including the following:

The Duke Energy logo is announced by screen readers as "photo image of Duke Energy".
There is low text contrast for white text when the video is also white or a light color.
The focus indicator is difficult to perceive.
There is no announcement for screen reader users when the volume slider is adjusted.
There are parsing errors, including but not limited to stray end tags and unclosed elements.
When text spacing is increased, "Watch Later" becomes "Watch La," which is more difficult to understand.

Recommendation

Remediate any issues you are able to address.
Tell third party content providers that they must make their content accessible.
Don't use providers of non-conformant third party content.
Use third party embedding systems that provide control over accessibility.
Manually or automatically check and block inaccessible third party content.
Provide accessible alternative formats for content that can't be remediated.
Tell users when third party content may not be accessible, and how they can access the content.

Resources

7.4

The iframe title does not adequately describe its purpose

The video is an <iframe> with the label "YouTube video player". This title does not let users know which video is in the <iframe>. Screen reader users do not have enough information to know whether or not they should enter the <iframe> content.

Recommendation

Provide a descriptive title for <iframe> elements when they contain content for a user.

Code example (simplified)

<iframe title="Video: Why Join Power Manager"></iframe>

For <iframe> elements that do not display content to users (e.g. it is used for programmatic reasons), take the following steps: Use CSS display:none or the hidden attribute

Example code indicating an <iframe> is not intended to be read.

<iframe name="..." hidden src="..." title="No user content" ...></iframe>

iframe.hidden { display:none; }

<iframe name="..." class="hidden" src="..." title="No user content" ...></iframe>

Resources

WCAG Technique: Providing descriptive labels

2.4.6 Headings and Labels AA

8. News and Resources

News and Resources Technical Details

Issue Description

Modification

STD

Count

PRIO

8.1

Active SVG does not have a text alternative

Links in the table open PDF documents. A PDF icon informs visual users that these links lead to PDFs. There is no text alternative for screen reader users. Additionally, the "PDF" text is very small and will be difficult to read for users with low vision.

Recommendation

Add "PDF" to the link text itself, and use aria-hidden="true' to hide the <svg> from assistive technologies. Also add focusable="false" to the <svg> element to prevent unnecessary tab stops.

Simplified code example

<a href="https://desitecoredev92-cd.azureedge.net/_/media/pdfs/our-company/ash-management/212492-asheville-3q21-monitoring-results.pdf?la=en&rev=009ac748bbac49149c7676ac52d343f7">

<svg aria-hidden="true" focusable="false">

... </svg>

<span class="flex-grow">Asheville 2021 3rd Quarter SOC Monitoring Report (PDF)</span>

</a>

Remediating this assertion will also solve for violations of the following success criteria:

1.4.5 Images of Text
2.4.4 Link Purpose

1.1.1 Non-text Content A

8.2

Sortable data tables are not defined and well formed

Data tables can be very useful components for conveying complicated information. These components can be difficult or impossible to navigate for keyboard only and screen reader users when not built using established design patterns.

The complex data table has the following issues:

No announcement when table is sorted.
No accessible name.
Contains parsing errors: the <tbody> element is improperly nested within the <table> element (after the <tfoot> element).
Direction of sort appears when the button is hovered but not when it's focused with a keyboard.

Recommendation

Ensure that data tables are well-formed:

For the table itself, use the <table> element (or an element with a table role for ARIA based tables). Note that the grid role is reserved for a widget that uses most of the same roles within it (identified below) but triggers a different interaction mode for screen reader users.
Ensure that the table does not have a presentation or none role.
Use a <caption> element to label the table. For ARIA based tables, use an ARIA labeling method such as aria-labelledby.
Use a <tr> element for each row, or the row role for rows in ARIA based tables.
Use the <th> element for row and column headers. To indicate what dimension the header applies to, the scope=col and scope=row attributes for row headers are implied by user agents assistive technology so are generally not needed. For ARIA based tables, use the columnheader and rowheader roles.
Use the <td> element for each cell (or an element with a cell role for ARIA based tables, gridcell if using the grid role).

For this <table> element, also ensure:

Sorting changes are announced to users. Use role="status" on an element within the <caption> element.
Sort direction is visually available at all times, or at least available when the button has keyboard focus.

To fix parsing issues:

Add the Check serialized DOM of current page (DOM Checking) and Check for WCAG 2.1 parsing compliance bookmarklets to your browser of choice.
Open the page you wish to check, then activate the DOM checking bookmarklet.
The W3C validator results for the page will be displayed, filter results using the Check for WCAG 2.1 parsing bookmarklet

Example of <caption> element with status update when table is sorted

<table> <caption>News and Resources <span role="status">sorted by title ascending</span></caption> ... </table>

Remediation this assertion will also fix violations for the following WCAG success criteria:

4.1.3 Status Messages
2.1.1 Keyboard
4.1.1. Parsing

1.3.1 Info and Relationships A

8.3

Focus order for show more button is not logical

When a user clicks the "Show More" button below the table, new table rows appear above the button, but keyboard focus remains on the button. Non-sighted screen reader users might not realize more information has populated above the button.

Recommendation

When a user presses the "Show More" button, programmatically shift focus to the first new link in the table. If a user presses the "Show Less" button, keep focus on the button itself.

Resources

Understanding Success Criterion 2.4.3: Focus Order

2.4.3 Focus Order A

9. Table

Table Technical Details

Issue Description

Modification

STD

Count

PRIO

9.1

Decorative images are not hidden from screen reader users

Icons in the first column of the table are decorative image elements that are not hidden from screen reader users.. This can cause confusion for screen reader users.

Recommendation

Use an empty string as text alternative alt="". This will ensure that the image is not announced by assistive technologies.

Recommended (simplified) markup

<img src="stock1.jpg" alt="">

Resources

Text alternatives for images

1.1.1 Non-text Content A

9.2

Data tables are not defined as well-formed tables with correct row and column headers

The data table has the following issues:

Does not use <th> elements. Uses headings instead.
No accessible name
Missing attributes: role(s), colspan, rowspan
Rows not correctly associated to headers
Some text is hard-coded as all caps in the HTML. This can lead screen readers to announce the words in acronyms and is more difficult to read for people with dyslexia.

Recommendation

Ensure that data tables are well-formed:

Use a <caption> element to label the table. For ARIA based tables, use an ARIA labeling method such as aria-labelledby.
Use a <tr> element for each row, or the row role for rows in ARIA based tables.
Use the <th> element for row and column headers. To indicate what dimension the header applies to, the scope=col and scope=row attributes for row headers are implied by user agents assistive technology so are generally not needed. For ARIA based tables, use the columnheader and rowheader roles.
Use the <td> element for each cell (or an element with a cell role for ARIA based tables, gridcell if using the grid role).

Additionally, remove headings. We recommend using sentence case. If this is unachievable, then use sentence case in the HTML and use CSS text-transform to transform the text to uppercase.

The following shows a simple HTML table:

<table> <caption>Contact Information</caption> <tr> <td></td> <th>Name</th> <th>Phone#</th> <th>Fax#</th> <th>City</th> </tr> <tr> <td>1.</td> <th>Joel Garner</th> <td>412-212-5421</td> <td>412-212-5400</td> <td>Pittsburgh</td> </tr> <tr> <td>2.</td> <th>Clive Lloyd</th> <td>410-306-1420</td> <td>410-306-5400</td> <td>Baltimore</td> </tr> <tr> <td>3.</td> <th>Gordon Greenidge</th> <td>281-564-6720</td> <td>281-511-6600</td> <td>Houston</td> </tr> </table>

The following shows the same structure but achieved through ARIA table roles:

<div role="table" aria-labelledby="Caption">

<div id="Caption">Contact Information</div>

<div role="row">

<div role="cell">

</div>

<div role="columnheader">Name</div>

<div role="columnheader">Phone#</div>

<div role="columnheader">Fax#</div>

<div role="columnheader">City</div>

</div> <div role="row">

<div role="cell">1.</div>

<div role="rowheader">Joel Garner</div>

<div role="cell">412-212-5421</div>

<div role="cell">412-212-5400</div>

<div role="cell">Pittsburgh</div>

</div> <div role="row">

<div role="cell">2.</div>

<div role="rowheader">Clive Lloyd</div>

<div role="cell">410-306-1420</div>

<div role="cell">410-306-5400</div>

<div role="cell">Baltimore</div>

</div>

<div role="row">

<div role="cell">3.</div>

<div role="rowheader">Gordon Greenidge</div>

<div role="cell">281-564-6720</div>

<div role="cell">281-511-6600</div>

<div role="cell">Houston</div>

</div> </div>

1.3.1 Info and Relationships A

10. Multi Video

Multi Video Technical Details

Issue Description

Modification

STD

Count

PRIO

10.1

Button does not indicate whether it is pressed

The video tile buttons do not indicate when they are selected. When a video tile button is selected, the video opens in the adjacent video player, but it does not trigger an announcement to assistive technology.

Recommendation

Ensure that when a video is selected, it triggers an announcement to assistive technology which conveys that the page content has updated.

Option 1

The best and most appropriate solution is to apply an aria-pressed attribute to each video tile button. Toggle the button to reflect whether that video is selected.

Simplified, recommended markup using aria-pressed attribute.

<button aria-pressed="true" aria label="Parental leave - Maria"> <img src="..." alt=""> </button>

Option 2

Create a live region. Apply aria-live="polite", role="status", aria-atomic="true" to a visually hidden <span>. When a video is selected, update this live region to describe/summarize the change in page i.e. "Parental leave - Maria video selected".

Simplified, recommended markup for a live region

<span aria-live="polite" role="status">Parental leave - Maria video selected</span>

4.1.2 Name, Role, Value A

10.2

Text alternative includes superfluous information

Each video tile button derives its accessible name from its descendant image's alt attribute. The alt attribute indicates that the text describing its image i.g. "Parental Leave - Chris Bethany Mosteller image". This information is unnecessary; the text alternative is meant to describe the control's purpose. Superfluous information in the text alternative increase the page noise and make it harder to understand a control's purpose.

Recommendation

Good alternative text should describe an image's purpose more than its contents. Remove "image" from the alt attribute. The text alternative could be further improved by noting that it is a video.

Simplified, recommended markup for a video tile button

<button>

<img alt="Parental Leave - Chris Bethany Mosteller video">

</button>

11. News and Resources

News and Resources Technical Details

Issue Description

Modification

STD

Count

PRIO

11.1

Filter control does not have a persistent visible label

The "show" <select> element has a label that is visually hidden until the user selects a value. The purpose of the control may not be clear to users.

Recommendation

Ensure that the "Show" label is always visible. Form controls that require user input must have an appropriate label that describes the expected input to all users. For form controls that have additional restrictions or input requirements (such as requiring a specific format or a specific piece of information that is not obvious from the label alone), some form of instruction must be present to inform the user of these specific restrictions or requirements. This information must be permanently available and cannot be removed once a value is entered in the control.

Resources

3.3.2 Labels or Instructions A

12. Push Down Panel

Push Down Panel Technical Details

Issue Description

Modification

STD

Count

PRIO

12.1

Elements that are not conveying headings are marked up as headings

When the content is expanded, the first text for each expanded section is marked up as a heading. This content is a repeat of the heading above it and is marked up as the same heading level (<h3>). This can be confusing for users, especially assistive technology users who navigate the page by heading.

Recommendation

Do not use heading markup for text that does not serve as a descriptive label for the section of content that follows it.

1.3.1 Info and Relationships A

12.2

Underlined buttons appear visually as links

Button text, such as "get your bill online" and the "Close" button for expanded content is underlined when hovered by a mouse user. This visually signifies a link. Links navigate to a new location while buttons produce actions. If users click a link, they expect to navigate to another page or another part of the page. Clicking these controls expands and collapses content. This can create a confusing experience.

Recommendation

Remove the underline when the buttons are hovered. Use a different way of expressing hover state. For example, add a box around the button text when hovered.

13. Flipboard

Flipboard Technical Details

Issue Description

Modification

STD

Count

PRIO

13.1

Decorative images are not hidden from screen reader users

The image within each link is decorative. Each image has inappropriate alt="image" attribute. This extra "page noise" can cause confusion for screen reader users. Screen reader users will wonder whether the image is actually informative and its information is not adequately announced to them.

Recommendation

Use an empty string as text alternative alt="". This will ensure that the image is not announced by assistive technologies.

Recommended (simplified) markup

<img alt="" src="...">

Resources

Text alternatives for images

1.1.1 Non-text Content A

13.2

Inappropriate title attribute

The "Awards" link has a title attribute with a long, incomprehensible string sitecore:item:InternalLinkTreeview_AC99B8D34494492B9AFA2BD36DF3DDC6, that resembles a file name, as its value. When focus is set to the link, screen readers announce this title attribute as part of the link's accessible name/description.

Recommendation

Remove the title attribute.

Recommended (simplified) markup for the link with the title attribute removed

<a href="/our-company/about-us/awards"> ... </a>

Resources

Using the HTML title attribute

2.4.6 Headings and Labels AA

13.3

Flashcard is not keyboard accessible

The links, "Giving Back", "Awards", "Our History", and "Diversity", have behavior that could be described as flashcards or flipboards. When the mouse moves over a card, it displays a description of the link. However, this interaction cannot be triggered via keyboard.

It's important to note that the link description can be accessed by screen reader users, even when it is visually hidden. This is good behavior.

Recommendation

When focus is set to the link, display the description; extend the behavior for hover state to focus state.

2.1.1 Keyboard A

14. Tab

Tab Technical Details

Issue Description

Modification

STD

Count

PRIO

14.1

Decorative images are not hidden from screen reader users

Each element with role="tab" has has an aria-label attribute which provides the control's accessible name. Each tab's descendant image has an alt attribute which has a redundant text alternative e.g. alt="icon". Given the aria-label attribute on the image's functional container, the element with role="tab", the descendant image can be considered decorative; its alt attribute is unnecessary.

Recommendation

Use an empty string as text alternative alt="" for the image within each tab. This will ensure that the image is not announced by assistive technologies. When an image is indicated as decorative through the alt="" attribute, there's no possible benefit to doubling-up with the aria-hidden attribute. Remove the unnecessary aria-hidden attribute from the <img>.

Recommended (simplified) markup for decorative image within a tab

<button aria-controls="panel-site-requirements" aria-selected="false" role="tab" tabindex="-1" type="button"> <img alt=""> <span>Site Requirements</span> </button>

Resources

Text alternatives for images

1.1.1 Non-text Content A

14.2

Tab panel is difficult to operate using a mouse

When the browser width is less than 750 CSS pixels, two of the tabs are offscreen. A mouse user cannot scroll through the list of tabs to view these two offscreen tabs, "REC Ownership" and "Low-Moderate Participation".

This assertion is a best practice because issues with using a site via the mouse are primarily not covered under WCAG. However, regardless of whether the assertion is a WCAG error, the issue has a legitimate impact on the site's overall user experience.

Recommendation

There are multiple approaches which could be used.

Option 1

At smaller viewports, add a scrollbar to the tab panel. Mouse users can then select the scroll bar and move through the tab list.

Option 2

At smaller viewports, use an accordion tab rather than a tab panel.

14.3

Content requires both horizontal and vertical scrolling when resized to a width of 320 CSS px / height of 256 CSS px

In smaller viewports or when zoomed in, content requires scrolling in two dimensions. Users with low vision will find it difficult to read and understand content.

At smaller viewports, two of the six tab controls are offscreen, which requires horizontal scrolling within the tab list.

Beyond the challenge for low-vision users, mouse users will face difficulty scrolling the tab list. It is not possible, using a mouse sans scroll wheel, to view the other tabs in the list. This aspect of the tab panel is discussed in a separate best practice assertion.

Recommendation

There are multiple approaches which could be used to make the tab panel reflow for smaller viewports. A scrollbar could be added to the tab list or the tab panel could have a responsive adaptation where it becomes an accordion tab.

Resources

1.4.10 Reflow AA

15. Hero Stock Chart

Hero Stock Chart Technical Details

Issue Description

Modification

STD

Count

PRIO

15.1

Decorative images are not hidden from screen reader users

The image of a stock chart is a decorative image. It has redundant alt="chart" attribute.

The image, representing the background for the section has inappropriate alt="patterned background for duke Energy grant notification copy" attribute.

These unnecessary text alternatives extra "page noise" can cause confusion for screen reader users.

Recommendation

Use an empty string as text alternative alt="". This will ensure that the image is not announced by assistive technologies.

Recommended (simplified) markup

<img src="stock1.jpg" alt="">

Resources

Text alternatives for images

1.1.1 Non-text Content A

16. Accordion (FAQ)

Accordion (FAQ) Technical Details

Issue Description

Modification

STD

Count

PRIO

16.1

Decorative images are not hidden from screen reader users

There is an image of a question mark above the "Frequently Asked Questions" heading. This image is announced to screen reader users as "Image". This can cause confusion for screen reader users. Users will wonder if there is an informative image that is not adequately announced to them.

Recommendation

Use an empty string as text alternative alt="". This will ensure that the image is not announced by assistive technologies.

Recommended (simplified) markup

<img alt="" src="https://desitecoredev92-cd.azureedge.net/_/media/images/svg/account/iconquestion.svg?h=100&la=en&w=100&rev=cff914c360f8411c80ba3ccfad6880f5">

Resources

Text alternatives for images

1.1.1 Non-text Content A

16.2

Link does not have any text

Within the section with the heading "If I am making a payment dated today, can I cancel it after I have clicked the 'Submit' button?" there is a link without any text. This link is invisible on the page, but it is still announced to screen reader users. Because there is no associated text, the full URL is announced instead. This can be confusing and difficult to parse for screen reader users.

Recommendation

Remove the link, hide it from all users via the hidden attribute or CSS display:none, or add text and ensure it is available to all users.

Recommended markup (if not removed)

<a href="/home/billing/credit-card-debit-card-or-electronic-check-payments">Card or eCheck Payments</a>

This also fails the following WCAG success criteria, which will also be resolved by remediation of this assertion: 4.1.2 Name, Role, Value

Resources

2.4.4 Link Purpose (In Context) A

16.3

Link name is ambiguous in isolation

In the section with the heading, "How do I receive my $10 Restaurant.com dining certificate?" there is a link that is simply labelled "this page". Within the context of this paragraph, it's clear that this is a link to the terms and conditions page. Some screen reader users navigate using TAB or encounter all links within one list. Without the context of the surrounding text, these users will not know where the link "this page" leads.

Recommendation

Include the destination of the link within the link text itself.

Recommended Markup (simplified)

<p>... Please view our <a href="http://www.prizelabs.com/termsandconditions/" target="_blank">complete terms and conditions</a>. ....</p>

Issue Description

Modification

STD

Count

PRIO

No issues identified.

18. More Info

More Info Technical Details

Issue Description

Modification

STD

Count

PRIO

18.1

A decorative image is not hidden from screen reader users

The decorative image, of an info "i" icon, is not hidden from assistive technologies. It has a redundant alt="image" attribute. This can cause confusion for screen reader users.

Recommendation

Use an empty string as text alternative alt="". This will ensure that the image is not announced by assistive technologies.

Recommended (simplified) markup

<img alt="" src=...">

Resources

Text alternatives for images

1.1.1 Non-text Content A

18.2

Dynamically-added content is not added to the focus order directly after the element that exposed the content

Content that is revealed when a user interacts with a control does not follow immediately after the control that triggers its appearance, either in reading or tab order.

When the "Show All" disclosure button is activated, the new content loads above the button. This is confusing for assistive technology users. When assistive technology users expand a widget, they expect the new content to be the next element on the page.

Recommendation

When a keyboard user activates a control (such as a button) that triggers the reveal or injection of previously hidden content (such as a new section in a form), they must be able to navigate quickly and easily to this added content. The new content must follow the trigger element in both the reading and tab order.

The most straightforward solution here is to add the new content after the "Show All" button and not before the button.

The button has an aria-expanded attribute to indicate whether the content it controls is expanded or collapsed. When the aria-expanded attribute is toggled, it triggers an announcement to assistive technology. This is positive behavior. The label also switches between "Show More" and "Show less". As a rule of thumb, one should not change an ARIA property and the label together. If the label changes, the button has already changed state in a sense. However, a change in label alone does not trigger an announcement to assistive technology.

While it is not required, it is suggested to provide a name for the button which does not switch between "Show more" and "Show less". A suitable name could be "Plan disclaimer" or "Plan details".

Simplified, recommended markup for expandable/collapsible widget with content following the disclosure button

<button aria-expanded="true">Plan Disclaimer</button>

<p>These products or services are not part of the regulated utility services offered by Duke Energy Carolinas ("DEC") and ... </p>

Resources

Understanding Focus Order

2.4.3 Focus Order A

Engagement Overview

Engagement Details

User Journeys and Components Reviewed:

Findings

User Journey and Component Findings

Summary of Priority Findings by WCAG 2.1 Success Criteria

Explanation of Table Headers

User Journey: Common Components

1. Secondary Nav

Secondary Nav Technical Details

2. Footer

Footer Technical Details

3. Footer

Footer Technical Details

4. Primary Nav

Primary Nav Technical Details

5. Footer

Footer Technical Details

6. Common Issues

Common Issues Technical Details

User Journey: Component Library

7. Video Player

Video Player Technical Details

8. News and Resources

News and Resources Technical Details

9. Table

Table Technical Details

10. Multi Video

Multi Video Technical Details

11. News and Resources

News and Resources Technical Details

12. Push Down Panel

Push Down Panel Technical Details

13. Flipboard

Flipboard Technical Details

14. Tab

Tab Technical Details

15. Hero Stock Chart

Hero Stock Chart Technical Details

16. Accordion (FAQ)

Accordion (FAQ) Technical Details

17. Related Links

Related Links Technical Details

18. More Info

More Info Technical Details

User Journey: Feedback

19. Your Feedback Aside

Your Feedback Aside Technical Details