Accessibility criteria implemented in WebSite X5

WebSite X5 aims to help anyone, even those with no technical skills, create a complete, professional website that is optimized for search engines, mobile navigation, and also accessible. For non-developers, modifying page code to meet accessibility requirements can be complex or even impossible. That’s why WebSite X5 automatically handles many technical aspects of accessibility, allowing users to build websites without writing a single line of code.

In this guide, we will explore which accessibility criteria WebSite X5 supports and how they are implemented.

WebSite X5 and WCAG: which criteria are implemented and how

As we know, web accessibility is regulated by the Web Content Accessibility Guidelines (WCAG), a set of guidelines developed by the World Wide Web Consortium (W3C) to ensure that digital content is accessible to everyone, including people with disabilities.

The WCAG guidelines are structured around four core principles (Perceivable, Operable, Understandable, and Robust) and define success criteria grouped into three levels of compliance (A, AA, and AAA).

Specifically, WebSite X5 follows the WCAG 2.0 version, with WCAG 2.1 and 2.2 being extensions of this version. It implements 15 of the 25 Level A criteria, plus 3 additional criteria from other WCAG versions/levels. The implemented criteria are addressed:

• Automatically → WebSite X5 automatically ensures compliance without user intervention by generating correct, standard-compliant code.
• With assisted implementation → WebSite X5 provides tools to support accessibility, but users must take action. For example, WebSite X5 offers an option for adding alternative text for images, but the site creator must enter an appropriate description.

WebSite X5 does not address success criteria that depend entirely on content creator decisions. However, many of these criteria fall under Level AAA, which is considered advanced and not always required by law.

Specifically, the accessibility success criteria implemented automatically or with assistance by WebSite X5 are as follows:

• 1.1.1 Non-text Content
• 1.3.1 Information and Relationships
• 1.3.2 Meaningful Sequence
• 1.3.4 Orientation
• 2.1.1 Keyboard
• 2.1.2 No Keyboard Trap
• 2.1.4 Character Key Shortcuts
• 2.4.1 Bypass Blocks
• 2.4.2 Page Titled
• 2.4.3 Focus Order
• 2.4.4 Link Purpose (In Context)
• 3.1.1 Language of Page
• 3.2.1 On Focus
• 3.3.1 Error Identification
• 3.3.2 Labels or Instructions
• 4.1.1 Parsing
• 4.1.2 Name, Role, Value

1.1.1 Non-text Content

Guideline 1.1 requires that a text alternative be provided for any non-text content so that it can be transformed into other forms usable according to users' needs: Braille, speech synthesis, symbols, etc.

To meet success criterion 1.1.1, WebSite X5 allows text alternatives to be added to all non-text elements (images, animations, videos, audio) that are imported, except for purely decorative ones, which correctly do not require them (see: How to write alternative text for non-text content). The text alternatives for graphic elements generated by the software are instead inserted automatically. This applies, for example, to navigation buttons in galleries or icons and buttons in blog article and e-commerce product cards.

As required, all text alternatives are inserted into the page code using the HTML attributes alt, title, aria-label, and/or aria-labelledby. The HTML element <label> and the HTML attributes aria-label, aria-labelledby, and aria-describedby are also used for all input fields (search fields on the site and in the product catalog, login and registration pages, contact form objects) to provide guidance on how to fill in these fields.

#tip - Success criterion 1.1.1 also considers Captcha. At the moment, WebSite X5's Captcha is not yet accessible. Therefore, we recommend using Google reCaptcha. See: How to choose the CAPTCHA for your website.

1.3.1 Information and Relationships

Guideline 1.3 requires that content can be presented in different ways (e.g., with simpler layouts) without losing information or structure.

Specifically, success criterion 1.3.1 requires that relationships, structures, and correlations that are visually apparent on a webpage must also be programmatically determinable via code so that they remain intact even when the page is displayed differently.

To meet this criterion, it is necessary to generate semantic code for web pages.

WebSite X5 automatically fulfills this success criterion by using the correct tags and relating information through proximity or specific attributes. The use of semantic HTML elements (<a>, <button>, <input>, <dialog>, <nav>, <article>, etc.) and/or the HTML role attribute allows screen readers and other navigation tools to recognize and present the function of each element and facilitate faster navigation.

1.3.2 Meaningful Sequence

In reference to Guideline 1.3, this specific success criterion requires that if the order in which content is presented affects its meaning, it must also be determined programmatically (i.e., via code).

This criterion is resolved in an assisted mode, meaning that WebSite X5 provides the site author with the ability to determine the order of page elements and thus define the content hierarchy. The software then automatically "translates" this hierarchy into semantic code.

1.3.4 Screen Orientation

Also referring to Guideline 1.3, this success criterion requires that content can be used in any screen orientation.

WebSite X5 automatically meets this criterion since it does not impose any restrictions on the vertical or horizontal presentation of content.

2.1.1 Keyboard

Guideline 2.1 requires that all functions be available via keyboard, and Success Criterion 2.1.1 specifies that keyboard operation must be possible without specific time limits for individual keystrokes.

#Tip - For more information on keyboard navigation, see How to Ensure Accessible Keyboard Navigation

WebSite X5 automatically fulfills this criterion by using semantic elements (<a>, <button>, <input>, <dialog>) to enable keyboard navigation. Additionally, WebSite X5 inserts the HTML tabindex attribute and implements keyboard management for UI components that do not have a dedicated HTML element (e.g., the price range selector in product catalog search or the tabbed view in text and table objects).

#Tip - Currently, for the Image Object, zoom and manual movement modes cannot yet be controlled via keyboard. 

2.1.2 No Keyboard Trap

Also related to Guideline 2.1, this success criterion specifies that it must always be possible to move the focus out of a selected element, ensuring that keyboard users do not get "trapped" within subsections of a page.

WebSite X5 automatically fulfills this criterion by using the HTML tabindex attribute and implementing keyboard navigation management to allow movement through all page elements (focus can enter and exit each element using the Tab key).

2.1.4 Character Key Shortcuts

This success criterion of Guideline 2.1 requires that if character key shortcuts are defined, users must have the option to disable them, remap them, or ensure they are only active when the component is focused.

Since WebSite X5 does not define any character key shortcuts, this criterion is automatically satisfied.

2.4.1 Bypass Blocks

Guideline 2.4 requires that user support functionalities be provided to help navigate, find content, and determine their position within the website.

Specifically, Success Criterion 2.4.1 states that a mechanism must be provided to allow users to bypass blocks of content that repeat across multiple web pages.

WebSite X5 automatically satisfies this success criterion by implementing hidden links that allow users to skip repeated sections of the page, making it easier and quicker to access the main content. Specifically, the inserted links include:

• A link at the beginning of the page to skip directly to the main content.
• A link at the start of menus to skip to the first content after the menu.
• A link at the start of the product catalog search panel to skip to the product list.
• A link at the start of each blog sidebar section to skip to the next section.
• A link at the bottom of the page to return to the main content.

2.4.2 Page Titles

As part of Guideline 2.4, Success Criterion 2.4.2 requires that web pages have titles that describe their topic and purpose.

WebSite X5 addresses this criterion in assisted mode: it prompts the author to specify the title of each page and, using the <title> tag, inserts the entered text into the <head> section of the generated HTML page.

#tip - The <title> tag is automatically generated by WebSite X5 using the page name (set in Step 3 during Site Map creation) and the 'Page Title' (set through the 'Page Properties' window). If you want to customize the <title> tag, go to 'Step 3 - Map', select the page you want to modify, and click on the 'Properties' button. In the 'SEO' tab, enable the 'Tag Title' option and enter the desired title in the appropriate field.  

2.4.3 Focus Order

As part of Guideline 2.4, Success Criterion 2.4.3 states that if a web page can be navigated sequentially and the navigation sequences affect meaning and functionality, the elements that can receive focus must do so in an order that preserves their meaning and operability.

To automatically fulfill this criterion, WebSite X5 generates the page code in a way that:

• HTML elements in the page code follow the same order in which they are displayed on the screen. This ensures that when navigating using the keyboard, components receive focus in the correct sequence.
• The code for dynamic elements (e.g., pop-ups, dialogs, advertisements, etc.) is inserted near the content they are related to, using the HTML element <dialog> to enable:
• Automatic focus shift to the newly added content;
• Focus confinement within the content if it is "modal";
• Restoration of the previous focus position when the content is closed.
• Focus is automatically set on the text input field in the product catalog search page and the site search page, thanks to the HTML autofocus attribute.

2.4.4 Link Purpose (In Context)

As part of Guideline 2.4, Success Criterion 2.4.4 states that the purpose of each link must be determinable either from the link text alone or from the link text combined with contextual content that can be programmatically determined.

The goal of this criterion is to ensure that users can easily understand the purpose of links so they can decide whether to follow them. Ideally, the link text itself should be sufficient to clarify its function. However, it is also acceptable for the link’s purpose to be clarified through its context, provided that it is properly associated using appropriate ARIA techniques.

WebSite X5 automatically fulfills the requirements of Criterion 2.4.4 in all cases where it generates a link on its own. For links inserted by the user, it provides the option to specify alternative textual content.

3.1.1 Page Language

Guideline 3.1 requires making text readable and understandable. Within this guideline, Success Criterion 3.1.1 specifies that the default language setting for each web page must be programmatically determined.

WebSite X5 meets this criterion automatically by using the HTML lang attribute in the <html> tag to specify the language of the page content.

#tip - You can set the 'Content Language' through the dedicated option available in the 'Step 1 - Settings > General Information' window.

3.2.1 On Focus

Guideline 3.2 requires ensuring that web pages appear and function in a predictable manner.

Specifically, Success Criterion 3.2.1 states that when a component of a web page receives focus, it must not automatically trigger a context change, meaning a significant alteration that could disorient the user.

WebSite X5 meets this criterion automatically as it does not execute any context changes when an element receives focus, as required.

3.3.1 Error Identification

Guideline 3.3 requires assisting users in avoiding errors and facilitating their correction.

Specifically, Success Criterion 3.3.1 states that if an error is automatically detected in data input (for example, during the completion of a form), a text message describing the error must be provided. This message should be as specific as possible to help users understand what went wrong.

WebSite X5 automatically resolves this criterion by generating semantically correct code for email forms. Specifically, the HTML attribute aria-invalid is used in form fields that contain validation errors (missing or invalid data), and HTML elements <dialog> with role=alertdialog are employed to communicate any input errors to the user.

3.3.2 Labels or Instructions

Also within Guideline 3.3, Success Criterion 3.3.2 states that when content requires user input, labels or instructions must be provided to clarify what data is expected.

WebSite X5 meets this criterion in an assisted mode by generating semantically correct code. Specifically:

• Uses HTML elements <label> and/or HTML attributes aria-label, aria-labelledby, and aria-describedby to provide input field guidance (search fields on the website and in the product catalog, login and registration pages, contact form objects).
• Uses the HTML attribute aria-required for all required input fields.

Additionally, WebSite X5 automatically inserts descriptions for all fields generated by the software (e.g.,

search fields on the website and in the product catalog, login and registration pages), while allowing the site author to specify descriptions for all custom fields created in the Contact Form object.

4.1.1 Parsing

Guideline 4.1 states that maximum compatibility with current and future user agents, including assistive technologies, must be ensured.

Specifically, Success Criterion 4.1.1 requires that, in content implemented using markup languages, elements must have complete start and end tags, be nested according to their specifications, not contain duplicate attributes, and have unique IDs unless exceptions are permitted by the specifications.

WebSite X5 automatically meets this success criterion as it generates syntactically valid HTML code, ensuring compliance with all listed requirements.

4.1.2 Name, Role, Value

Also under Guideline 4.1, Success Criterion 4.1.2 requires that all user interface components (including but not limited to: form elements, links, and script-generated components):

• Have their name and role programmatically determined; 
• Have states, properties, and values that can be set by the user programmatically; 
• Provide notifications for state changes to user agents, including assistive technologies.

The purpose of this success criterion is to ensure that assistive technologies (AT) can correctly interact with user interface controls. When standard controls are used, this process is straightforward. However, when custom controls are created or interface elements are programmed to serve a different role or function than usual, additional measures must be taken. 

To meet this criterion, WebSite X5 automatically generates semantic code for user interface components. For example:

• Uses semantic HTML elements such as <a>, <button>, <input>, <dialog>, <nav>, <article>, and/or the HTML role attribute, along with the HTML attributes aria-label, aria-labelledby, and/or aria-describedby to specify the name and role of each component on the page.
• Adds the HTML attributes aria-selected and aria-expanded to indicate the state of user interface components (selected/deselected, expanded/collapsed).
• Uses the HTML attributes aria-controls and aria-owns to define interactions between components.
• Implements the aria-live attribute to notify users of dynamic content changes in specific areas of the page.