Kent State University
During my graduate program in User Experience Design, students are required to perform a review of a website’s accessibility. I was assigned the Steampowered e-shop, a popular video game and software sales platform.
This assignment included development of an accessibility evaluation plan, audit, synthesis of a report with recommendations for remediation.
Valve Software’s Steam Powered online storefront is the leading e-shop for computer software as well as a forum for community content such as discussions, mod development, and hosting of user reviews. As stewards of gaming’s most valued platform: we are committed to ensuring an equitably accessible online storefront.
To meet this expectation and deliver a world-class experience for the entire Steam community, its customers, and our coworkers: The User Experience Design (UXD) department is to conduct an inclusive audit for the purpose of identifying issues for remediation by the Web Operations (Web Ops) department. This audit’s results will educate stakeholders on the expectations for commitment of resources to the remediation, which will assist in defining priorities, workflows, and timelines in parallel to ongoing development and implementation of new features.
Ensuring the Steam platform aligns to our commitment to providing an unparalleled experience for our users by addressing barriers to accessibility. Enhancing user-satisfaction, engagement, retention, and fostering a more inclusive community.
Conducting this evaluation and remediating identified accessibility issues will ensure compliance with latest accessibility standards, specifically the Web Content Accessibility Guidelines (WCAG) 2.1. This approach proactively mitigates risks of legal challenges by reinforcing Valve’s commitment to industry best-practices, making the platform equitably accessible to those with and without need of accommodation or assistive technology.
Valve’s commitment to accessibility meets legal requirements and stands to enhance the brand’s value proposition to current and potential users. By being at the forefront of accessibility and inclusivity within the gaming industry, Valve is positioned to strengthen its reputation as a leader in equitably accessible digital experiences.
Employing automated testing across multiple pages will assist in identifying systemic issues with content management system templates.
Employing manual testing supplements automated testing processes, addressing nuanced accessibility issues not captured during the automated process. This combined, comprehensive testing approach maximizes effectiveness.
The UXD team will strive toward achieving a minimum of WCAG 2.1 AA compliance standard, creating an accessible digital storefront. Criteria for success and benchmarks for standards are to be clearly defined and tracked throughout the evaluation process. Issues and actions taken to remediate will be reported during weekly status update as well as issue-tracking document.
This evaluation will likely uncover challenges accessibility faced by users and staff alike. These findings will be categorized, prioritized, and remediated based on severity and impact enabling UXD and Web Ops teams to address critical issues promptly and systematically.
Documentation of issues identified will be meticulously documented as will efforts to remediate. Reports on fixes are recommended to be included in the platform’s news channel to communicate changes to users.
Remediation of the identified issues is expected to improve user experience for all users of the Steam platform. Increased user engagement, satisfaction, and retention will be measured by UXD and Web Ops
This report describes the results of an accessibility evaluation conducted on Steam Powered e-shop.
Also provided in this report are recommendations for bringing Steam Powered into compliance with the World Wide Web Consortium’s Web Accessibility Initiative (W3C WAI) for Web Content Authoring Guidelines (WCAG), version 2.1. The WCAG can be found at this URL: https://www.w3.org/TR/WCAG21/
Below is a summary of the project goals and scope.
The goals of this project were to conduct an accessibility evaluation of Steam Powered using three evaluation methods:
Employing automated testing across multiple pages will assist in identifying systemic issues with content management system templates.
Employing manual testing supplements automated testing processes, addressing nuanced accessibility issues not captured during the automated process. This combined, comprehensive testing approach maximizes effectiveness.
Experience flows tested include:
This evaluation covered the following areas of the site:
Pages tested include the Home, Search, Results, Product Information, Account Creation, Sign-In, Cart, and Checkout pages.
Usability of these sites for a user relying on keyboard-only navigation and a screen reader; and whether or not a sale can be completed by such a user.
With the value to the Steam Powered e-shop falling under three categories:
There is a significant number of global accessibility issues:
All found issues are considered to be global, or prevalent across all sites. Concluding the issues could be corrected by making revisions within the e-shop’s Content Management System (CMS) templates.
It is recommended Standard Operating Procedures (SOP) and guidelines be amended and put into practice requiring new content containing media include mandatory fields that, if left blank, would prevent submission. New submissions should be routed into a workflow that manually verifies appropriate descriptive alt-text, heading, and strong tags are used, failing this check would return to the submitter with notes and prevent the product from being added to the e-shop until resubmitted and found to be compliant. This would only prevent the majority of found issues going forward. To correct the thousands of issues currently present will require several hundreds of hours manually adding property descriptive text and tags. This can, potentially, be made the responsibility of the product’s publisher with a deadline to remedy before removal from the e-shop; however this would mean legacy products no longer supported by their developer would cease to be available.
The CMS CSS templates requires correction for visual contrast or, alternatively, addition of a control added that allows a user to select a high-contrast version of the site, available whether a user is signed-in or not, and retaining the setting based on user-account preferences.
The Americans with Disabilities Act (ADA) defines a disability as “physical or mental impairment that substantially limits one or more major life activities.” In regards to
There are several types of disabilities, including:
According to the CDC, 61 million people or more than one-quarter (25.7%) of adults in the United States reported living with at least one disability. Persons with disabilities are protected by several federal laws including:
Assistive Technologies (AT) are products such as equipment and software systems used to improve access to information by improving or circumventing functional capabilities of persons with disabilities.
Examples of AT are:
Web Content Accessibility Guidelines (WCAG) 2.1 defines how to make Web content more accessible to people with disabilities. Accessibility involves a wide range of disabilities, including visual, auditory, physical, speech, cognitive, language, learning, and neurological disabilities. Although these guidelines cover a wide range of issues, they are not able to address the needs of people with all types, degrees, and combinations of disability. These guidelines also make Web content more usable by older individuals with changing abilities due to aging and often improve usability for users in general.
Web accessibility depends not only on accessible content but also on accessible Web browsers and other user agents. Authoring tools also have an important role in Web accessibility. For an overview of how these components of Web development and interaction work together, see:
User walkthrough using keyboard-only navigation and Google’s Chrome Screen Reader, a free browser plugin, for the following steps:
Information and user interface components must be presentable to users in ways they can perceive.
Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language.
|
Checkpoint |
Description |
Page |
Level |
Pass / Fail |
Elaboration And Techniques For Achieving Conformance |
|
1.1.1 |
Non-text Content – Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language. |
All |
A |
Fail |
Images do not have descriptive alternate text (ALT text) or contained placeholder content such as the word “image” or “picture”. Techniques: •ARIA6: Using aria-label to provide labels for objects •ARIA10: Using aria-labelled by to provide a text alternative for non-text content •G196: Using a text alternative on one item within a group of images that describes all items in the group •H35: Providing text alternatives on applet elements •H37: Using alt attributes on img elements |
Provide alternatives for time-based media.
|
Checkpoint |
Description |
Page |
Level |
Pass / Fail |
Elaboration And Techniques For Achieving Conformance |
|
1.2.1 |
Checkpoints under this guideline were not tested – no time-based media present. |
Home, Product Information |
A |
Fail |
Prerecorded video does not contain text equivalents. Techniques: •Situation A: If the content is prerecorded audio-only: •G158: Providing an alternative for time-based media for audio-only content •Situation B: If the content is prerecorded video-only: •G159: Providing an alternative for time-based media for video-only content •G166: Providing audio that describes the important video content and describing it as such |
Create content that can be presented in different ways (for example simpler layout) without losing information or structure.
|
Checkpoint |
Description |
Page |
Level |
Pass / Fail |
Elaboration And Techniques For Achieving Conformance |
|
1.3.1 |
Info and Relationships – Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. |
All |
A |
Fail |
CSS heading styles used. Incorrect use of font-weight markup. Techniques •H42: Using h1-h6 to identify headings •H49: Using semantic markup to mark emphasized or special text •G115: Using semantic elements to mark up structure •G117: Using text to convey information that is conveyed by variations in presentation of text |
|
1.3.2 |
Meaningful Sequence – When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined. |
All |
A |
Fail |
Content element sequencing out of order. Techniques •G57: Ordering the content in a meaningful sequence for all the content in the Web page •Marking sequences in the content as meaningful using one of the following techniques AND G57: Ordering the content in a meaningful sequence for those sequences •H34: Using a Unicode right-to-left mark (RLM) or left-to-right mark (LRM) to mix text direction inline (HTML) •H56: Using the dir attribute on an inline element to resolve problems with nested directional runs (HTML) •C6: Positioning content based on structural markup (CSS) •C8: Using CSS letter-spacing to control spacing within a word (CSS) •C27: Making the DOM order match the visual order (CSS) •FLASH15: Using the tabIndex property to specify a logical reading order and a logical tab order in Flash (Flash) •PDF3: Ensuring correct tab and reading order in PDF documents (PDF) •SL34: Using the Silverlight Default Tab Sequence and Altering Tab Sequences With Properties (Silverlight) |
|
1.3.3 |
Sensory Characteristics – Instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape, size, visual location, orientation, or sound. |
All |
A |
Pass |
Operating and understanding operation of the e-shop does not rely solely on sensory characteristics. |
Create content that can be presented in different ways (for example simpler layout) without losing information or structure.
|
Checkpoint |
Description |
Page |
Level |
Pass / Fail |
Elaboration And Techniques For Achieving Conformance |
|
1.3.4 |
Orientation – Content does not restrict its view and operation to a single display orientation, such as portrait or landscape, unless a specific display orientation is essential. |
All |
AA |
Pass |
E-shop does respond to changes in device orientation. |
|
1.3.5 |
Identify Input Purpose – The purpose of each input field collecting information about the user can be programmatically determined when: •The input field serves a purpose identified in the Input Purposes for User Interface Components section; and •The content is implemented using technologies with support for identifying the expected meaning for form input data. |
All |
AA |
Pass |
Form fields purpose can be programmatically determined by browser for auto-completion of attributes. |
Make it easier for users to see and hear content including separating foreground from background.
|
Checkpoint |
Description |
Page |
Level |
Pass / Fail |
Elaboration And Techniques For Achieving Conformance |
|
1.4.1 |
Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. |
All |
A |
Fail |
Links indicated using only text color Techniques •G182: Ensuring that additional visual cues are available when text color differences are used to convey information •G183: Using a contrast ratio of 3:1 with surrounding text and providing additional visual cues on focus for links or controls where color alone is used to identify them |
|
1.4.2 |
If any audio on a Web page plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume independently from the overall system volume level. |
N/A |
A |
N/A |
N/A |
|
1.4.3 |
The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following: Large Text Large-scale text and images of large-scale text have a contrast ratio of at least 3:1; Incidental Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement. Logotypes Text that is part of a logo or brand name has no contrast requirement. |
All |
AA |
Fail |
Text and background colors do not have enough contrast Techniques •Situation A: text is less than 18 point if not bold and less than 14 point if bold •G18: Ensuring that a contrast ratio of at least 4.5:1 exists between text (and images of text) and background behind the text •G148: Not specifying background color, not specifying text color, and not using technology features that change those defaults •G174: Providing a control with a sufficient contrast ratio that allows users to switch to a presentation that uses sufficient contrast •SL13: Providing A Style Switcher To Switch To High Contrast (Silverlight) •Situation B: text is at least 18 point if not bold and at least 14 point if bold •G145: Ensuring that a contrast ratio of at least 3:1 exists between text (and images of text) and background behind the text •G148: Not specifying background color, not specifying text color, and not using technology features that change those defaults •G174: Providing a control with a sufficient contrast ratio that allows users to switch to a presentation that uses sufficient contrast •SL13: Providing A Style Switcher To Switch To High Contrast (Silverlight) |
Make it easier for users to see and hear content including separating foreground from background.
|
Checkpoint |
Description |
Page |
Level |
Pass / Fail |
Elaboration And Techniques For Achieving Conformance |
|
1.4.4 |
Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality. |
All |
AA |
Pass |
Excepting for captions and image-text, text can be resized without AT by up to 200% without loss of content or functionality. |
|
1.4.5 |
If the technologies being used can achieve the visual presentation, text is used to convey information rather than images of text except for the following: Customizable The image of text can be visually customized to the user’s requirements; Essential A particular presentation of text is essential to the information being conveyed. |
Home |
AA |
Fail |
Banners use images of text to convey information. Techniques •C22: Using CSS to control visual presentation of text •C30: Using CSS to replace text with images of text and providing user interface controls to switch •G140: Separating information and structure from presentation to enable different presentations •PDF7: Performing OCR on a scanned PDF document to provide actual text |
User interface components and navigation must be operable.
Make all functionality available from a keyboard.
|
Checkpoint |
Description |
Page |
Level |
Pass / Fail |
Elaboration And Techniques For Achieving Conformance |
|
2.1.1 |
Keyboard – All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user’s movement and not just the endpoints. |
Home, Search, Product Information, Cart |
A |
Fail |
Hidden scrollable content inaccessible using keyboard Techniques •G202: Ensuring keyboard control for all functionality •H91: Using HTML form controls and links •PDF3: Ensuring correct tab and reading order in PDF documents •PDF11: Providing links and link text using the Link annotation and the /Link structure element in PDF documents •PDF23: Providing interactive form controls in PDF documents •G90: Providing keyboard-triggered event handlers using one of the following techniques: •SCR20: Using both keyboard and other device-specific functions •SCR35: Making actions keyboard accessible by using the onclick event of anchors and buttons •SCR2: Using redundant keyboard and mouse event handlers |
|
2.1.2 |
No Keyboard Trap – If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away. |
All |
A |
Pass |
No instances required modified keyboard command to move focus from an element reachable using a standard command entry. |
Guideline 2.1 – Keyboard Accessible
Make all functionality available from a keyboard.
|
Checkpoint |
Description |
Page |
Level |
Pass / Fail |
Elaboration And Techniques For Achieving Conformance |
|
2.1.4 |
Character Key Shortcuts – If a keyboard shortcut is implemented in content using only letter (including upper- and lower-case letters), punctuation, number, or symbol characters, then at least one of the following is true: •Turn off: A mechanism is available to turn the shortcut off; •Remap: A mechanism is available to remap the shortcut to use one or more non-printable keyboard characters (e.g. Ctrl, Alt, etc); •Active only on focus: The keyboard shortcut for a user interface component is only active when that component has focus. |
All |
A |
Pass |
No keyboard shortcut implementation was found requiring a control to toggle on/off state, remapping of key, or an active only-on-focus state. |
Provide users enough time to read and use content.
|
Checkpoint |
Description |
Page |
Level |
Pass / Fail |
Elaboration And Techniques For Achieving Conformance |
|
2.2.3 |
Timing is not an essential part of the event or activity presented by the content, except for non-interactive synchronized media and real-time events. |
Product Information |
AAA |
Pass |
No page or element necessitates time-based interactions. |
Do not design content in a way that is known to cause seizures or physical reactions.
|
Checkpoint |
Description |
Page |
Level |
Pass / Fail |
Elaboration And Techniques For Achieving Conformance |
|
2.3.1 |
Web pages do not contain anything that flashes more than three times in any one second period, or the flash is below the general flash and red flash thresholds. |
All |
A |
Pass |
No flashing elements were observed during testing. |
Provide ways to help users navigate, find content, and determine where they are.
|
Checkpoint |
Description |
Page |
Level |
Pass / Fail |
Elaboration And Techniques For Achieving Conformance |
|
2.4.1 |
Bypass Blocks – A mechanism is available to bypass blocks of content that are repeated on multiple Web pages. |
All |
A |
Pass |
No blocks were found, but navigation at top and footer were consistent allowing for access to leave any page at any time. Breadcrumbing navigation also available for content category and product information. |
|
2.4.2 |
Page Titled – Web pages have titles that describe topic or purpose. |
All |
A |
Pass |
Pages were titled accurately, and read upon navigating to the page despite non-compliance for 2.4.3 |
|
2.4.3 |
Focus Order – If a Web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability. |
Search, Product Information, Account Creation, Sign-In, Cart |
A |
Fail |
Sequencing of navigation consistently began in page footer, out of view pane, and ordering was inconsistent between page types impeding operation. Techniques •G59: Placing the interactive elements in an order that follows sequences and relationships within the content •C27: Making the DOM order match the visual order •PDF3: Ensuring correct tab and reading order in PDF documents •SCR26: Inserting dynamic content into the Document Object Model immediately following its trigger element •SCR37: Creating Custom Dialogs in a Device Independent Way •SCR27: Reordering page sections using the Document Object Model |
Provide ways to help users navigate, find content, and determine where they are.
|
Checkpoint |
Description |
Page |
Level |
Pass / Fail |
Elaboration And Techniques For Achieving Conformance |
|
2.4.4 |
Link Purpose (In Context) – The purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general. |
All |
A |
Fail |
Links lack accessible names Related Techniques •H2: Combining adjacent image and text links for the same resource •H30: Providing link text that describes the purpose of a link for anchor elements •ARIA7: Using aria-labelledby for link purpose •ARIA8: Using aria-label for link purpose |
|
2.4.5 |
Multiple ways – More than one way is available to locate a Web page within a set of Web pages except where the Web Page is the result of, or a step in, a process. |
Account Creation, Sign-In, Cart |
AA |
Fail |
Less than two ways to reach each page Techniques: •G125: Providing links to navigate to related Web pages •G64: Providing a Table of Contents •PDF2: Creating bookmarks in PDF documents (PDF) •G63: Providing a site map •G161: Providing a search function to help users find content •G126: Providing a list of links to all other Web pages •G185: Linking to all of the pages on the site from the home page |
|
2.4.6 |
Headings and Labels – Headings and Labels |
All |
AA |
Fail |
Pages did not use headings, instead relying on CSS styling. Techniques •G130: Providing descriptive headings •G131: Providing descriptive labels |
|
2.4.7 |
Focus Visible – Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible. |
All |
AA |
Fail |
CSS borders and outline styles were sometimes difficult to see link focus outline, or were off visible pane (pages opened and focus began in footer, off-screen). Techniques •G149: Using user interface components that are highlighted by the user agent when they receive focus •C15: Using CSS to change the presentation of a user interface component when it receives focus •G165: Using the default focus indicator for the platform so that high visibility default focus indicators will carry over •G195: Using an author-supplied, visible focus indicator •C40: Creating a two-color focus indicator to ensure sufficient contrast with all components •SCR31: Using script to change the background color or border of the element with focus |
Make it easier for users to operate functionality through various inputs beyond keyboard.
|
Checkpoint |
Description |
Page |
Level |
Pass / Fail |
Elaboration And Techniques For Achieving Conformance |
|
2.5.1 |
Pointer Gestures All functionality that uses multipoint or path-based gestures for operation can be operated with a single pointer without a path-based gesture, unless a multipoint or path-based gesture is essential. |
All |
A |
Pass |
There were no instances where multipoint or path-based gestures were necessary. |
|
2.5.2 |
Pointer Cancellation For functionality that can be operated using a single pointer, at least one of the following is true: No Down-Event The down-event of the pointer is not used to execute any part of the function; Abort or Undo Completion of the function is on the up-event, and a mechanism is available to abort the function before completion or to undo the function after completion; Up Reversal The up-event reverses any outcome of the preceding down-event; Essential Completing the function on the down-event is essential. |
All |
A |
Pass |
Pointer cancellation operability conformed throughout the e-shop. |
|
2.5.3 |
Label In Name For user interface components with labels that include text or images of text, the name contains the text that is presented visually. |
All |
A |
Fail |
UI elements were not properly labeled. Techniques •G208: Including the text of the visible label as part of the accessible name •G211: Matching the accessible name to the visible label |
Make it easier for users to operate functionality through various inputs beyond keyboard.
|
Checkpoint |
Description |
Page |
Level |
Pass / Fail |
Elaboration And Techniques For Achieving Conformance |
|
2.5.4 |
Motion Actuation Functionality that can be operated by device motion or user motion can also be operated by user interface components and responding to the motion can be disabled to prevent accidental actuation, except when: Supported Interface The motion is used to operate functionality through an accessibility supported interface; Essential The motion is essential for the function and doing so would invalidate the activity. |
All |
A |
Pass |
No pages tested necessitates motion actuation. |
Information and the operation of user interface must be understandable.
Make text content readable and understandable.
|
Checkpoint |
Description |
Page |
Level |
Pass / Fail |
Elaboration And Techniques For Achieving Conformance |
|
3.1.1 |
Language of Page – The default human language of each Web page can be programmatically determined. |
All |
A |
Fail |
Lang attributes invalid Techniques •H57: Using language attributes on the html element (HTML) •FLASH13: Using HTML language attributes to specify language in Flash content (Flash) •PDF16: Setting the default language using the /Lang entry in the document catalog of a PDF document (PDF) •PDF19: Specifying the language for a passage or phrase with the Lang entry in PDF documents (PDF) |
|
3.1.2 |
Language of Parts – The human language of each passage or phrase in the content can be programmatically determined except for proper names, technical terms, words of indeterminate language, and words or phrases that have become part of the vernacular of the immediately surrounding text. |
All |
AA |
Fail |
Lang attributes invalid Techniques •H58: Using language attributes to identify changes in the human language. •PDF19: Specifying the language for a passage or phrase with the Lang entry in PDF documents. |
Make Web pages appear and operate in predictable ways.
|
Checkpoint |
Description |
Page |
Level |
Pass / Fail |
Elaboration And Techniques For Achieving Conformance |
|
3.2.1 |
On Focus – When any component receives focus, it does not initiate a change of context. |
All |
A |
Pass |
No instance was found where focus created a change of context. |
|
3.2.2 |
On Output – Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component. |
All |
A |
Pass |
Changing settings of UI components did not create automatic change of context. |
Make Web pages appear and operate in predictable ways.
|
Checkpoint |
Description |
Page |
Level |
Pass / Fail |
Elaboration And Techniques For Achieving Conformance |
|
3.2.3 |
Consistent Navigation – Navigational mechanisms that are repeated on multiple Web pages within a set of Web pages occur in the same relative order each time they are repeated, unless a change is initiated by the user. |
All |
AA |
Pass |
Navigation elements across pages were consistently placed at top and bottom in consistent ordering. |
|
3.2.4 |
Consistent Identification – Components that have the same functionality within a set of Web pages are identified consistently. |
All |
AA |
Pass |
Components with identical functionality operated consistently across all pages. |
Help users avoid and correct mistakes.
|
Checkpoint |
Description |
Page |
Level |
Pass / Fail |
Elaboration And Techniques For Achieving Conformance |
|
3.3.1 |
Error Identification – If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text. |
All |
A |
Pass |
Input errors were appropriate described in text. |
|
3.3.2 |
Labels or Instructions – Labels or instructions are provided when content requires user input. |
Product Information |
A |
Fail |
User age verification was not labeled and prevented user from proceeding. Techniques •G131: Providing descriptive labels AND one of the following: •ARIA1: Using the aria-describedby property to provide a descriptive label for user interface controls •ARIA9: Using aria-labelledby to concatenate a label from several text nodes •ARIA17: Using grouping roles to identify related form controls •G89: Providing expected data format and example •G184: Providing text instructions at the beginning of a form or set of fields that describes the necessary input •G162: Positioning labels to maximize predictability of relationships •G83: Providing text descriptions to identify required fields that were not completed •H90: Indicating required form controls using label or legend •PDF5: Indicating required form controls in PDF forms •H44: Using label elements to associate text labels with form controls •PDF10: Providing labels for interactive form controls in PDF documents •H71: Providing a description for groups of form controls using fieldset and legend elements •G167: Using an adjacent button to label the purpose of a field |
|
3.3.3 |
Error Suggestion – If an input error is automatically detected and suggestions for correction are known, then the suggestions are provided to the user, unless it would jeopardize the security or purpose of the content. |
All |
AA |
Pass |
Error detection present on fields. |
|
3.3.4 |
Error Prevention (Legal, Financial, Data) – For Web pages that cause legal commitments or financial transactions for the user to occur, that modify or delete user-controllable data in data storage systems, or that submit user test responses, at least one of the following is true: •Reversible: Submissions are reversible. •Checked: Data entered by the user is checked for input errors and the user is provided an opportunity to correct them. •Confirmed: A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission. |
All |
AA |
Pass |
No instances of irreversible data input were found. All fields were editable before confirmation. Confirmation prior to purchase is available on a separate page, allowing confirmation of information. |
Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.
In content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features.
|
Checkpoint |
Description |
Page |
Level |
Pass / Fail |
Elaboration And Techniques For Achieving Conformance |
|
4.1.1 |
Parsing – In content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features. |
All |
A |
Fail |
HTML forms have no accessible names Related Techniques •H44: Using label elements to associate text labels with form controls •H65: Using the title attribute to identify form controls when the label element cannot be used •G167: Using an adjacent button to label the purpose of a field •ARIA6: Using aria-label to provide labels for objects •ARIA9: Using aria-labelledby to concatenate a label from several text nodes •ARIA16: Using aria-labelledby to provide a name for user interface controls •ARIA14: Using aria-label to provide an invisible label where a visible label cannot be used |
|
4.1.2 |
Name, Role, Value – For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies. |
All |
A |
Fail |
Interface components lack names, roles, states, and properties Techniques •ARIA14: Using aria-label to provide an invisible label where a visible label cannot be used •ARIA16: Using aria-labelledby to provide a name for user interface controls •G108: Using markup features to expose the name and role, allow user-settable properties to be directly set, and provide notification of changes •H91: Using HTML form controls and links •H44: Using label elements to associate text labels with form controls •H64: Using the title attribute of the frame and iframe elements •H65: Using the title attribute to identify form controls when the label element cannot be used •H88: Using HTML according to spec •ARIA16: Using aria-labelledby to provide a name for user interface controls •G135: Using the accessibility API features of a technology to expose names and notification of changes •PDF10: Providing labels for interactive form controls in PDF documents •PDF12: Providing name, role, value information for form fields in PDF documents •G10: Creating components using a technology that supports the accessibility notification of changes •ARIA4: Using a WAI-ARIA role to expose the role of a user interface component •ARIA5: Using WAI-ARIA state and property attributes to expose the state of a user interface component •ARIA16: Using aria-labelledby to provide a name for user interface controls |
|
4.1.3 |
Status Messages – In content implemented using markup languages, status messages can be programmatically determined through role or properties such that they can be presented to the user by assistive technologies without receiving focus. |
All |
AA |
Fail |
In-content status messages required focus. Techniques •ARIA22: Using role=status to present status messages in combination with any of the following: •G199: Providing success feedback when data is submitted successfully •ARIA19: Using ARIA role=alert or Live Regions to Identify Errors in combination with any of the following: •G83: Providing text descriptions to identify required fields that were not completed •G84: Providing a text description when the user provides information that is not in the list of allowed values •G85: Providing a text description when user input falls outside the required format or values •G177: Providing suggested correction text •G194: Providing spell checking and suggestions for text input |
After attempting to use Steam Powered e-shop with the Google Chrome screen reader plugin and via keyboard navigation, we concluded that people who use screen readers or who do not use pointing devices such as a mouse or trackpad cannot always proceed through to make a purchase.
If they are able to proceed, they would not be informed of the final pricing, to include tax, after the search results page: a minimum of 4 pages prior to checkout for users with an existing account. Users who need to create a new account take up to 8 pages. This is an unethical and deceptive process that conceals final pricing.
|
Accessibility Issue |
Severity |
Location & Description |
Why This Happened |
|
1.1 Text alternatives 1.3 Adaptable 1.4 Distinguishable 2.4 Navigable 2.5 Input modalities 3.1 Readable 3.3 Input Assistance 4.1 Parsing |
Critical – Visitor cannot continue |
Product Information page •Age Verification fields. Cart and Checkout page •Pricing does not receive focus. All pages •Alt-text missing from images or using non-descriptive placeholders. •Heading tags not in use. Cart pages •Navigation does not focus on price for product or cart total, focusing first on “remove from cart” then product name, then checkout button. |
Global lack of alt-text, labels, headings. Elements with key information are unable to receive focus when navigating with a keyboard. CMS enforces CSS-defined style instead of Heading tags. |
|
1.4 Distinguishable |
Severe Visitor may not be able to continue |
All pages •Color contrast for pricing tables and links is below conformance standards. |
Global CSS definitions for text color of pricing. |
|
1.2 Time-based media 2.1 Keyboard accessible 2.4 Navigable |
Minor Visitor may encounter difficulty but can continue |
All pages •Keyboard-only navigation starts in footer on page-load. Product information pages •Sequence of content (after starting in footer) moves to header, then sidebar, skips media gallery, and then goes to product’s “add to cart” button. |
Global lack of Heading the CMS loading per-page content after the global footer. |
After attempting to use Steam Powered e-shop with the Google Chrome screen reader plugin and via keyboard navigation, we concluded that people who use screen readers cannot always proceed through to make a purchase.
The process was unnecessarily difficult, images lacked descriptive text and modals that some modals, such as the home page’s lunar new year sale and half of the special offer banners, did not state what the product were selling. Some stated nothing at all. Valve’s proprietary products, such as the Steam Deck and Valve Index VR headset’s banners were the only products seen to have proper descriptive text. Heading tags were not properly defined, leaving users to guess what section of the page they were actually in.
After leaving the home page by entering a search: on the results page, screen readers default to reading the new page’s footer first. This forces unnecessary tabbing to navigate back to the top of the page. Images in search results used placeholder alt-text, but modals did contain product-specific descriptive text. However, pricing information was below the minimum contrast threshold and would not be readable some users. Selecting a product that was age-restricted brought testers to a page to verify their age, the screen reader again defaulted to starting at the footer. This age verification page does not state what it is, and tabbing to the form fields to enter a birthdate lacks context for the user. Testers were unable to proceed from this point on products that require age-verification. This means user relying on a screen reader would not be able to proceed to product information or subsequently purchase the title.
For products that did not require age verification, the order of elements again began in the footer, then returned to top-of-page navigation, followed by the right-hand sidebar, and after tabbing through the entire page would take users past the video player modal and into the product’s “add to cart” button without stating a price. Users relying on a screen reader would have no way of interfacing with the media gallery to operate it and play media, and they would get information out of sequence which could be confusing. Bundled products were available before single-product purchasing, which could lead a user to believe the only way to purchase a title is to pay for a more-expensive multi-product bundle, which can potentially be viewed as deceptive.
After adding a product to the cart, screen readers again start in the footer, and after navigating the rest of the page to get into the cart’s information the first ordered object is the “remove” button prior to stating the name of the product. Next is a thumbnail with the placeholder alt-text of “image” then the product title. Screen readers do not read the price for the product, skipping straight to the “purchase as a gift” then “purchase for myself” buttons. This trend continued through the login, account creation, and checkout pages. Elements were out of order and required tabbing through the entire footer, sidebars, and a reverse-ordering (using a right-to-left reading order) of controls on the same “line” in modals.
Without the contextual information of pricing in the product information pages, cart, and checkout pages: it is not feasible for a user operating without a pointing device and using a screen reader to purchase a product. If they are able to proceed, they would not be informed of the final pricing, to include tax, after the search results page: a minimum of 4 pages prior to checkout for users with an existing account. The places pricing was available was of low-contrast and even a partially-sighted user relying on a screen reader may not be able to read the product pricing either. Users who need to create a new account take up to 8. This is an unethical and potentially deceptive process that conceals final pricing.
A sighted user not using who does not use pointing devices such as a mouse or trackpad can proceed through to make a purchase in all cases. However the process was unnecessarily difficult.
After leaving the home page by entering a search: on the results page, the default tab location was consistently the new page’s footer. This forces unnecessary tabbing to navigate back to the top of the page. Selecting a product that was age-restricted brought testers to a page to verify their age, the screen reader again defaulted to starting at the footer. Testers were able to proceed from this point on products that require age-verification. This means a keyboard-only user would be able to proceed to product information or subsequently purchase the title.
For products that did not require age verification, the order of elements again began in the footer, then returned to top-of-page navigation, followed by the right-hand sidebar, and after tabbing through the entire page would take users past the video player modal and into the product’s “add to cart” button. A keyboard-only user would not be able to select videos to play view individual images or operate the controls within the player modal.
After adding a product to the cart, the cart page starts in the footer, and after navigating the rest of the page to get into the cart’s information the first ordered object is the “remove” button. Ordering is again inconsistent, skipping to the “purchase as a gift” then “purchase for myself” buttons. These trends continued through the login, account creation, and checkout pages. Elements were out of order and required tabbing through the entire footer, sidebars, and a reverse-ordering (using a right-to-left reading order) of controls on the same “line” in modals.
Pricing was consistently of low-contrast, so a keyboard-only user may not be able to read pricing until the cart page.
It is difficult but feasible for a user operating without a pointing device to purchase products.
The e-shop not usable to users relying solely on screen readers.
The e-shop is usable by sighted users with or without pointing devices, however it is difficult to use and low visual contrast in pricing is a consistent issue.
During all tested pages, only two images on the e-shop had descriptive text: banners for the Valve Index VR Headset and the Steam Deck handheld device.
Significant, intensive remediation is immediately required.
This will solve current stoppages for users of screen readers such as age verification and pricing information.