Compatible

4.1 Compatible

4.1 Compatible

Maximize compatibility with current and future user agents, including assistive technologies.

Parsing

(A)

4.1.1 Parsing

4.1.1 Parsing

In content implemented using markup language, 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.

9.4.1.1 Correct syntax

Relevance and applicability

This guideline is relevant when making your portal accessible.

General implementation

The correct HTML syntax is implemented in Intrexx.

Name, Role, Value

(A)

4.1.2 Name, Role, Value

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.

9.4.1.2 Name, Role, Value available

Description

This success criterion is primarily for Web authors who develop or script their own user interface components. Even for such self-authored parts of portal and application pages, it must be ensured that name and role can be determined by assistive technologies. (For example, standard HTML controls already meet this success criterion when used according to specification.)

Relevance and applicability

This guideline is relevant when making your portal accessible.

General implementation

As an author, you have the option of assigning ARIA roles and attributes for each element in the Accessibility tab.

If you develop your own elements, it is your responsibility as an author to provide them with appropriate ARIA roles and attributes.

Status Messages

(AA)

4.1.3 Status Messages

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.

9.4.1.3 Status messages programmatically available

Description

Status messages can provide information to the user on the success or results of an action, on the progress of a process, or on the existence of errors

Examples of status messages may include:

  • Form was successfully submitted (success message)

  • 5 search results (e.g. after filtering the results)

  • 3 errors in the form (if the client checks without reloading the page)

  • Page is loading (with visual loading indicator or a progress bar)

If status messages are generated on a portal or application page, then visually overlaid status messages should be awarded roles and properties with appropriate ARIA roles and attributes so that name and role can be determined by assistive technologies without taking focus.

Relevance and applicability

This guideline is relevant when making your portal accessible.

General implementation

As an author, you have the possibility to create and output your own status messages.