Software

Tilgængelighedskrav i relation til webtilgængelighedsloven for kapitel 11 i EN 301 549 version 3.2.1

De relevante krav i relation til webtilgængelighedsloven findes i bilag A i EN 301 549 version 3.2.1. Bilag A består af to tabeller, som oplister krav, der er relevante for henholdsvis websteder (tabel A.1) og mobilapplikationer (tabel A.2).

Hvert krav indeholder et direkte udtræk fra EN 301 549 version 3.2.1 og et link dertil.

Krav for websteder og mobilapplikationer

Where software is not designed to be isolated from its platform, and provides a user interface, that user interface shall follow the values of the user preferences for platform settings for: units of measurement, colour, contrast, font type, font size, and focus cursor except where they are overridden by the user.

NOTE 1: Software that is isolated from its underlying platform has no access to user settings in the platform and thus cannot adhere to them.

NOTE 2: For web content, the underlying platform is the user agent.

NOTE 3: This does not preclude the software from having additional values for a setting as long as there is one mode where the application will follow the system settings even if more restricted.

© ETSI 2021. All rights reserved

Læs klausulen i EN 301 549 version 3.2.1 [engelsk]
Authoring tools shall conform to clauses 11.8.2 to 11.8.5 to the extent that information required for accessibility is supported by the format used for the output of the authoring tool.

© ETSI 2021. All rights reserved

Læs klausulen i EN 301 549 version 3.2.1 [engelsk]
Authoring tools shall enable and guide the production of content that conforms to clauses 9 (Web content) or 10 (Non-Web content) as applicable.

NOTE: Authoring tools may rely on additional tools where conformance with specific requirements is not achievable by a single tool. For example, a video editing tool may enable the creation of video files for distribution via broadcast television and the web, but authoring of caption files for multiple formats may be provided by a different tool.

© ETSI 2021. All rights reserved

Læs klausulen i EN 301 549 version 3.2.1 [engelsk]
If the authoring tool provides restructuring transformations or re-coding transformations, then accessibility information shall be preserved in the output if equivalent mechanisms exist in the content technology of the output.

NOTE 1: Restructuring transformations are transformations in which the content technology stays the same, but the structural features of the content are changed (e.g. linearizing tables, splitting a document into pages).

NOTE 2: Re-coding transformations are transformations in which the technology used to encode the content is changed.

© ETSI 2021. All rights reserved

Læs klausulen i EN 301 549 version 3.2.1 [engelsk]
If the accessibility checking functionality of an authoring tool can detect that content does not meet a requirement of clauses 9 (Web) or 10 (Non-web documents) as applicable, then the authoring tool shall provide repair suggestion(s).

NOTE: This does not preclude automated and semi-automated repair which is possible (and encouraged) for many types of content accessibility problems.

© ETSI 2021. All rights reserved

Læs klausulen i EN 301 549 version 3.2.1 [engelsk]
When an authoring tool provides templates, at least one template that supports the creation of content that conforms to the requirements of clauses 9 (Web) or 10 (Non-web documents) as applicable shall be available and identified as such.

© ETSI 2021. All rights reserved

Læs klausulen i EN 301 549 version 3.2.1 [engelsk]

Krav særligt for mobilapplikationer

Where ICT is non-web software that provides a user interface and that supports access to assistive technologies for screen reading, it shall satisfy WCAG 2.1 Success Criterion 1.1.1 Non-text Content.

NOTE: CAPTCHAs do not currently appear outside of the Web. However, if they do appear, this guidance is
accurate.

© ETSI 2021. All rights reserved

Læs klausulen i EN 301 549 version 3.2.1 [engelsk]
Where ICT is non-web software that provides a user interface which is closed to assistive technologies for screen reading, it shall meet requirement 5.1.3.6 (Speech output for Non-text content).

© ETSI 2021. All rights reserved

Læs klausulen i EN 301 549 version 3.2.1 [engelsk]
Where ICT is non-web software that provides a user interface and that supports access to assistive technologies for screen reading and where pre-recorded auditory information is not needed to enable the use of closed functions of ICT, it shall satisfy the WCAG 2.1 Success Criterion 1.2.1 Audio-only and Video-only (Prerecorded).

NOTE: The alternative can be provided directly in the software - or provided in an alternate version that meets the success criterion.

© ETSI 2021. All rights reserved

Læs klausulen i EN 301 549 version 3.2.1 [engelsk]
11.1.2.1.2.1 Pre-recorded audio-only (closed functionality)

Where ICT is non-web software that provides a user interface which is closed to assistive technologies for screen reading and where pre-recorded auditory information is needed to enable the use of closed functions of ICT, the functionality of software that provides a user interface shall meet requirement 5.1.5 (Visual output for auditory information).

11.1.2.1.2.2 Pre-recorded video-only (closed functionality)

Where ICT is non-web software that provides a user interface which is closed to assistive technologies for screen reading, it shall meet requirement 5.1.3.7 (Speech output for video information)

© ETSI 2021. All rights reserved

Læs klausulen i EN 301 549 version 3.2.1 [engelsk]
Where ICT is non-web software that provides a user interface, it shall satisfy the WCAG 2.1 Success Criterion 1.2.2 Captions (Prerecorded).

NOTE: The WCAG 2.1 definition of "captions" notes that "in some countries, captions are called subtitles". They are also sometimes referred to as "subtitles for the hearing impaired". Per the definition in WCAG 2.1, to meet this success criterion, whether called captions or subtitles, they would have to provide "synchronized visual and / or text alternative for both speech and non-speech audio information needed to understand the media content" where non-speech information includes "sound effects, music, laughter, speaker identification and location".

© ETSI 2021. All rights reserved

Læs klausulen i EN 301 549 version 3.2.1 [engelsk]
Where ICT is non-web software that provides a user interface and that supports access to assistive technologies for screen reading, it shall satisfy the WCAG 2.1 Success Criterion 1.2.3 Audio Description or Media Alternative (Prerecorded).

NOTE 1: The WCAG 2.1 definition of "audio description" says that "audio description" is "also called 'video description' and 'descriptive narration'".

NOTE 2: Secondary or alternate audio tracks are commonly used for this purpose.

© ETSI 2021. All rights reserved

Læs klausulen i EN 301 549 version 3.2.1 [engelsk]
Where ICT is non-web software that provides a user interface which is closed to assistive technologies for screen reading, it shall meet requirement 5.1.3.7 (Speech output for video information).

© ETSI 2021. All rights reserved

Læs klausulen i EN 301 549 version 3.2.1 [engelsk]
Where ICT is non-web software that provides a user interface, it shall satisfy the WCAG 2.1 Success Criterion 1.2.5 Audio Description (Pre-recorded).

NOTE 1: The WCAG 2.1 definition of "audio description" says that audio description is "Also called 'video description' and 'descriptive narration'".

NOTE 2: Secondary or alternate audio tracks are commonly used for this purpose.

© ETSI 2021. All rights reserved

Læs klausulen i EN 301 549 version 3.2.1 [engelsk]
Where ICT is non-web software that provides a user interface and that supports access to assistive technologies for screen reading, it shall satisfy the WCAG 2.1 Success Criterion 1.3.1 Info and Relationships.

NOTE: In software, programmatic determinability is best achieved through the use of accessibility services provided by platform software to enable interoperability between software and assistive technologies and accessibility features of software. (see clause 11.5 Interoperability with assistive technology).

© ETSI 2021. All rights reserved

Læs klausulen i EN 301 549 version 3.2.1 [engelsk]
Where ICT is non-web software that provides a user interface and that supports access to assistive technologies for
screen reading, it shall satisfy the WCAG 2.1 Success Criterion 1.3.2 Meaningful Sequence.

© ETSI 2021. All rights reserved

Læs klausulen i EN 301 549 version 3.2.1 [engelsk]
Where ICT is non-web software that provides a user interface and supports access to assistive technologies for screen reading, it shall satisfy the WCAG 2.1 Success Criterion 1.3.5 Identify Input Purpose.

© ETSI 2021. All rights reserved

Læs klausulen i EN 301 549 version 3.2.1 [engelsk]
Where ICT is non-web software that provides a user interface and is closed to assistive technologies, in at least one mode of operation the ICT shall present to the user, in an audio form, the purpose of each input field collecting information about the user when the input field serves a purpose identified in the WCAG 2.1 Input Purposes for User Interface Components section

© ETSI 2021. All rights reserved

Læs klausulen i EN 301 549 version 3.2.1 [engelsk]

Where ICT is non-web software that provides a user interface, it shall satisfy the success criterion in Table 11.1.

**Table 11.1: Software success criterion: Audio control**
If any audio in a software 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.
NOTE 1: Since any part of a software that does not meet this success criterion can interfere with a user's ability to use the whole software, all content in the software (whether or not it is used to meet other success criteria) shall meet this success criterion. NOTE 2: This success criterion is identical to the WCAG 2.1 Success Criterion 1.4.2 Audio Control replacing "on a Web page" with "in a software", "any content" with "any part of a software", "whole page" with "whole software", "on the Web page" with "in the software", removing "See Conformance Requirement 5: Non-Interference" and adding note 1.

Læs klausulen i EN 301 549 version 3.2.1 [engelsk]

Where ICT is non-web software that provides a user interface and that supports access to enlargement features of platform or assistive technology, it shall satisfy the WCAG 2.1 Success Criterion 1.4.4 Resize Text.

NOTE 1: Content for which there are software players, viewers or editors with a 200 percent zoom feature would automatically meet this success criterion when used with such players, unless the content will not work with zoom.

NOTE 2: This success criterion is about the ability to allow users to enlarge the text on screen at least up to 200 % without needing to use assistive technologies. This means that the application provides some means for enlarging the text 200 % (zoom or otherwise) without loss of content or functionality or that the application works with the platform features that meet this requirement.

© ETSI 2021. All rights reserved

Læs klausulen i EN 301 549 version 3.2.1 [engelsk]
Where ICT is non-web software that provides a user interface which is not able to access the enlargement features of platform or assistive technology, it shall meet requirement 5.1.4 (Functionality closed to text enlargement).

NOTE: Because the text rendering support in a closed environment may be more limited than the support found in user agents for the Web, meeting the present clause in a closed environment may place a much heavier burden on the content author.

© ETSI 2021. All rights reserved

Læs klausulen i EN 301 549 version 3.2.1 [engelsk]
Where ICT is non-web software that provides a user interface and that supports access to assistive technologies for screen reading, it shall satisfy the WCAG 2.1 Success Criterion 1.4.5 Images of Text.

© ETSI 2021. All rights reserved

Læs klausulen i EN 301 549 version 3.2.1 [engelsk]
Where ICT is non-web software that provides a user interface which is closed to assistive technologies for screen reading, it shall meet requirement 5.1.3.6 (Speech output for non-text content).

© ETSI 2021. All rights reserved

Læs klausulen i EN 301 549 version 3.2.1 [engelsk]

Where ICT is non-web software that provides a user interface it shall satisfy the success criterion in Table 11.2.

**Table 11.2: Software success criterion: Reflow**
Content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions for: Vertical scrolling content at a width equivalent to 320 CSS pixels; Horizontal scrolling content at a height equivalent to 256 CSS pixels; Except for parts of the content which require two-dimensional layout for usage or meaning.
NOTE 1: 320 CSS pixels is equivalent to a starting viewport width of 1.280 CSS pixels wide at 400 % zoom. For non-web software which are designed to scroll horizontally (e.g. with vertical text), the 256 CSS pixels is equivalent to a starting viewport height of 1.024 px at 400 % zoom. NOTE 2: Examples of content which require two-dimensional layout are images, maps, diagrams, video, games, presentations, data tables, and interfaces where it is necessary to keep toolbars in view while manipulating content. NOTE 3: This success criterion is identical to the WCAG 2.1 Success Criterion 1.4.10 Reflow replacing the original WCAG 2.1 notes with notes 1 and 2, above.

Læs klausulen i EN 301 549 version 3.2.1 [engelsk]

Where ICT is non-web software that provides a user interface and that does not have a fixed size content layout area that is essential to the information being conveyed, it shall satisfy WCAG 2.1 Success Criterion 1.4.12 Text spacing.

© ETSI 2021. All rights reserved

Læs klausulen i EN 301 549 version 3.2.1 [engelsk]
Where ICT is non-web software that provides a user interface and that supports access to keyboards or a keyboard interface, it shall satisfy the WCAG 2.1 Success Criterion 2.1.1 Keyboard.

NOTE: This does not imply that software is required to directly support a keyboard or "keyboard interface". Nor does it imply that software is required to provide a soft keyboard. Underlying platform software may provide device independent input services to applications that enable operation via a keyboard. Software that supports operation via such platform device independent services would be operable by a keyboard
and would comply.

© ETSI 2021. All rights reserved

Læs klausulen i EN 301 549 version 3.2.1 [engelsk]
Where ICT is non-web software that provides a user interface which is closed to keyboards or keyboard interface, it shall meet requirement 5.1.6.1 (Operation without keyboard interface: Closed functionality).

© ETSI 2021. All rights reserved

Læs klausulen i EN 301 549 version 3.2.1 [engelsk]

Where ICT is non-web software that provides a user interface, it shall satisfy the success criterion in Table 11.3.

**Table 11.3: Software success criterion: No keyboard trap**
If keyboard focus can be moved to a component of the software 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.
NOTE 1: Since any part of a software that does not meet this success criterion can interfere with a user's ability to use the whole software, it is necessary for all content in the software (whether or not it is used to meet other success criteria) to meet this success criterion. NOTE 2: Standard exit methods may vary by platform. For example, on many desktop platforms, the Escape key is a standard method for exiting. NOTE 3: This success criterion is identical to the WCAG 2.1 Success Criterion 2.1.2 No Keyboard Trap replacing "content", "page" and "Web page" with "software", removing "See Conformance Requirement 5: NonInterference" and with the addition of note 2 above and with note 1 above re-drafted to avoid the use of the word "shall".

Læs klausulen i EN 301 549 version 3.2.1 [engelsk]

Where ICT is non-web software that provides a user interface which is closed to keyboards or keyboard interface, it shall meet requirement 5.1.6.1 (Operation without keyboard interface: Closed functionality).

© ETSI 2021. All rights reserved

Læs klausulen i EN 301 549 version 3.2.1 [engelsk]

Where ICT is non-web software that provides a user interface, it shall satisfy the success criterion in Table 11.4.

**Table 11.4: Software success criterion: Timing adjustable**
For each time limit that is set by the software, at least one of the following is true: Turn off: The user is allowed to turn off the time limit before encountering it; or Adjust: The user is allowed to adjust the time limit before encountering it over a wide range that is at least ten times the length of the default setting; or Extend: The user is warned before time expires and given at least 20 seconds to extend the time limit with a simple action (for example, "press the space bar"), and the user is allowed to extend the time limit at least ten times; or Real-time Exception: The time limit is a required part of a real-time event (for example, an auction), and no alternative to the time limit is possible; or Essential Exception: The time limit is essential and extending it would invalidate the activity; or 20 Hour Exception: The time limit is longer than 20 hours.
NOTE 1: This success criterion helps ensure that users can complete tasks without unexpected changes in content or context that are a result of a time limit. This success criterion should be considered in conjunction with WCAG 2.1 Success Criterion 3.2.1, which puts limits on changes of content or context as a result of user action. NOTE 2: This success criterion is identical to the WCAG 2.1 Success Criterion 2.2.1 Timing Adjustable replacing "the content" with "software" and with the words "WCAG 2.1" added before the word "Success Criterion" in note 1 above.

Læs klausulen i EN 301 549 version 3.2.1 [engelsk]

Where ICT is non-web software that provides a user interface, it shall satisfy the success criterion in Table 11.5.

**Table 11.5: Software success criterion: Pause, stop, hide**
For moving, blinking, scrolling, or auto-updating information, all of the following are true: Moving, blinking, scrolling: For any moving, blinking or scrolling information that (1) starts automatically, (2) lasts more than five seconds, and (3) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it unless the movement, blinking, or scrolling is part of an activity where it is essential; and Auto-updating: For any auto-updating information that (1) starts automatically and (2) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it or to control the frequency of the update unless the auto-updating is part of an activity where it is essential.
NOTE 1: For requirements related to flickering or flashing content, refer to WCAG 2.1 Guideline 2.3. NOTE 2: This success criteria is applicable to all content in the software (whether or not there is an alternate accessible mode of operation of the software) since any part of a software that does not meet this success criterion can interfere with a user's ability to use the whole software (including a user interface element that enables the user to activate the alternate accessible mode of operation). NOTE 3: Content that is updated periodically by software or that is streamed to the user agent is not required to preserve or present information that is generated or received between the initiation of the pause and resuming presentation, as this may not be technically possible, and in many situations could be misleading to do so. NOTE 4: An animation that occurs as part of a preload phase or similar situation can be considered essential if interaction cannot occur during that phase for all users and if not indicating progress could confuse users or cause them to think that content was frozen or broken. NOTE 5: This is to be applied to all content. Any content, whether informative or decorative, that is updated automatically, blinks, or moves may create an accessibility barrier. NOTE 6: This success criterion is identical to the WCAG 2.1 Success Criterion 2.2.2 Pause, Stop, Hide replacing "page" and "Web page" with "software", removing "See Conformance Requirement 5: Non-Interference" in note 2 of the success criterion, with the words "WCAG 2.1" added before the word "Guideline" in note 1 above, with note 2 above re-drafted to avoid the use of the word "must" and with the addition of note 5 above.

Læs klausulen i EN 301 549 version 3.2.1 [engelsk]

Where ICT is non-web software that provides a user interface, it shall satisfy the success criterion in Table 11.6.

**Table 11.6: Software success criterion: Three flashes or below threshold**
Software does 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.
NOTE 1: This success criteria is applicable to all content in the software (whether or not there is an alternate accessible mode of operation of the software) since any part of a software that does not meet this success criterion can interfere with a user's ability to use the whole software (including a user interface element that enables the user to activate the alternate accessible mode of operation). NOTE 2: This success criterion is identical to the WCAG 2.1 Success Criterion 2.3.1 Three Flashes or Below Threshold replacing "Web pages" with "software", "the whole page" with "the whole software", "the Web page" with "the software" and removing "See Conformance Requirement 5: Non-Interference" and with note 1 above re-drafted to avoid the use of the word "must".

Læs klausulen i EN 301 549 version 3.2.1 [engelsk]

Where ICT is non-web software that provides a user interface, it shall satisfy the success criterion in Table 11.7.

**Table 11.7: Software success criterion: Focus order**
If software can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability.
NOTE: This success criterion is identical to the WCAG 2.1 Success Criterion 2.4.3 Focus order replacing "Web page" with "software"

Læs klausulen i EN 301 549 version 3.2.1 [engelsk]

Where ICT is non-web software that provides a user interface, it shall satisfy the WCAG 2.1 Success Criterion 2.4.6 Headings and Labels.

NOTE: In software, headings and labels are used to describe sections of content and controls respectively. In some cases it may be unclear whether a piece of static text is a heading or a label. But whether treated as a label or a heading, the requirement is the same: that if they are present they describe the topic or purpose of the item(s) they are associated with.

© ETSI 2021. All rights reserved

Læs klausulen i EN 301 549 version 3.2.1 [engelsk]

Where ICT is non-web software that provides a user interface, it shall satisfy the success criterion in Table 11.8.

**Table 11.8: Software success criterion: 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.
NOTE 1: This requirement applies to non-web software that interprets pointer actions (i.e. this does not apply to actions that are required to operate the user agent or assistive technology). NOTE 2: This success criterion is identical to the WCAG 2.1 Success Criterion 2.5.1 Pointer Gestures replacing the original WCAG 2.1 note with note 1 above.

Læs klausulen i EN 301 549 version 3.2.1 [engelsk]

Where ICT is non-web software that provides a user interface, it shall satisfy the success criterion in Table 11.9.

**Table 11.9: Software success criterion: 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.
NOTE 1: Functions that emulate a keyboard or numeric keypad key press are considered essential. NOTE 2: This requirement applies to non-web software that interprets pointer actions (i.e. this does not apply to actions that are required to operate the user agent or assistive technology). NOTE 3: This success criterion is identical to the WCAG 2.1 Success Criterion 2.5.2 Pointer Cancellation replacing the original WCAG 2.1 note with notes 1 and 2 above.

Læs klausulen i EN 301 549 version 3.2.1 [engelsk]

Where ICT is non-web software that provides a user interface and that supports access to assistive technologies for screen reading, it shall satisfy the success criterion in Table 11.10.

**Table 11.10: Software success criterion: Language of software**
The default human language of software can be programmatically determined.
NOTE 1: Where software platforms provide a "locale / language" setting, applications that use that setting and render their interface in that "locale / language" would comply with this success criterion. Applications that do not use the platform "locale / language" setting but instead use an accessibility-supported method for exposing the human language of the software would also comply with this success criterion. Applications implemented in technologies where assistive technologies cannot determine the human language and that do not support the platform "locale / language" setting may not be able to meet this success criterion in that locale / language. NOTE 2: This success criterion is identical to the WCAG 2.1 Success Criterion 3.1.1 Language of page, replacing "each web page" with "software" and with the addition of note 1 above.

Læs klausulen i EN 301 549 version 3.2.1 [engelsk]

Where ICT is non-web software that provides a user interface which is closed to assistive technologies for screen reading, it shall meet requirement 5.1.3.14 (Spoken languages).

© ETSI 2021. All rights reserved

Læs klausulen i EN 301 549 version 3.2.1 [engelsk]
Where ICT is non-web software that provides a user interface, it shall satisfy the WCAG 2.1 Success Criterion 3.2.1 On Focus.

NOTE: Some compound documents and their user agents are designed to provide significantly different viewing and editing functionality depending upon what portion of the compound document is being interacted with (e.g. a presentation that contains an embedded spreadsheet, where the menus and toolbars of the user agent change depending upon whether the user is interacting with the presentation content, or the embedded spreadsheet content). If the user uses a mechanism other than putting focus on that portion of the compound document with which they mean to interact (e.g. by a menu choice or special keyboard gesture), any resulting change of context would not be subject to this success criterion because it was not caused by a change of focus.

© ETSI 2021. All rights reserved

Læs klausulen i EN 301 549 version 3.2.1 [engelsk]
Where ICT is non-web software that provides a user interface and that supports access to assistive technologies for screen reading, it shall satisfy the WCAG 2.1 Success Criterion 3.3.1 Error Identification.

© ETSI 2021. All rights reserved

Læs klausulen i EN 301 549 version 3.2.1 [engelsk]
Where ICT is non-web software that provides a user interface which is closed to assistive technologies for screen reading, it shall meet requirement 5.1.3.15 (Non-visual error identification).

© ETSI 2021. All rights reserved

Læs klausulen i EN 301 549 version 3.2.1 [engelsk]

Where ICT is non-web software that provides a user interface, it shall satisfy the success criterion in Table 11.11.

**Table 11.11: Software success criterion: Error prevention (legal, financial, data)**
For software 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.
NOTE: This success criterion is identical to the WCAG 2.1 Success Criterion 3.3.4 Error Prevention (Legal, Financial, Data) replacing "web pages" with "software".

Læs klausulen i EN 301 549 version 3.2.1 [engelsk]

Where ICT is non-web software that provides a user interface and that supports access to any assistive technologies, it shall satisfy the success criterion in Table 11.12.

**Table 11.12: Software success criterion: Parsing**
For software that uses markup languages, in such a way that the markup is separately exposed and available to assistive technologies and accessibility features of software or to a user-selectable user agent, 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.
NOTE 1: Start and end tags that are missing a critical character in their formation, such as a closing angle bracket or a mismatched attribute value quotation mark are not complete. NOTE 2: Markup is not always available to assistive technology or to user selectable user agents such as browsers. In such cases, conformance to this [requirement] would have no impact on accessibility as it can for web content where it is exposed. NOTE 3: Examples of markup that is separately exposed and available to assistive technologies and to user agents include but are not limited to: documents encoded in HTML, ODF, and OOXML. In these examples, the markup can be parsed entirely in two ways: (a) by assistive technologies which may directly open the document, (b) by assistive technologies using DOM APIs of user agents for these document formats. NOTE 4: Examples of markup used internally for persistence of the software user interface that are never exposed to assistive technology include but are not limited to: XUL, and FXML. In these examples assistive technology only interacts with the user interface of generated software. NOTE 5: This success criterion is identical to the WCAG 2.1 Success Criterion 4.1.1 Parsing replacing "In content implemented using markup languages" with "For software that uses markup languages, in such a way that the markup is separately exposed and available to assistive technologies and accessibility features of software or to a user-selectable user agent" with the addition of notes 2, 3 and 4 above.

Læs klausulen i EN 301 549 version 3.2.1 [engelsk]

Where ICT is non-web software that provides a user interface and that supports access to any assistive technologies, it shall satisfy the success criterion in Table 11.13.

**Table 11.13: Software success criterion: 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.
NOTE 1: This success criterion is primarily for software developers who develop or use custom user interface components. Standard user interface components on most accessibility-supported platforms already meet this success criterion when used according to specification. NOTE 2: For conforming to this success criterion, it is usually best practice for software user interfaces to use the accessibility services provided by platform software. These accessibility services enable interoperability between software user interfaces and both assistive technologies and accessibility features of software in standardised ways. Most platform accessibility services go beyond programmatic exposure of name and role, and programmatic setting of states, properties and values (and notification of same), and specify additional information that could or should be exposed and / or set (for instance, a list of the available actions for a given user interface component, and a means to programmatically execute one of the listed actions). NOTE 3: This success criterion is identical to the WCAG 2.1 Success Criterion 4.1.2 Name, Role, Value replacing the original WCAG 2.1 note with: "This success criterion is primarily for software developers who develop or use custom user interface components. Standard user interface components on most accessibility supported platforms already meet this success criterion when used according to specification." and the addition of note 2 above.

Læs klausulen i EN 301 549 version 3.2.1 [engelsk]

Where the software provides a user interface it shall use the applicable documented platform accessibility services. If the documented platform accessibility services do not allow the software to meet the applicable requirements of clauses 11.5.2.5 to 11.5.2.17, then software that provides a user interface shall use other documented services to interoperate with assistive technology.

NOTE: The term "documented platform accessibility services" refers to the set of services provided by the platform according to clauses 11.5.2.1 and 11.5.2.2.

It is best practice to develop software using toolkits that automatically implement the underlying platform accessibility services.

© ETSI 2021. All rights reserved

Læs klausulen i EN 301 549 version 3.2.1 [engelsk]
Where the software provides a user interface it shall, by using the services as described in clause 11.5.2.3, make the user interface elements' role, state(s), boundary, name, and description programmatically determinable by assistive technologies.

© ETSI 2021. All rights reserved

Læs klausulen i EN 301 549 version 3.2.1 [engelsk]
Where the software provides a user interface it shall, by using the services as described in clause 11.5.2.3, make the row and column of each cell in a data table, including headers of the row and column if present, programmatically determinable by assistive technologies.

© ETSI 2021. All rights reserved

Læs klausulen i EN 301 549 version 3.2.1 [engelsk]
Where the software provides a user interface, it shall, by using the services as described in clause 11.5.2.3, make the current value of a user interface element and any minimum or maximum values of the range, if the user interface element conveys information about a range of values, programmatically determinable by assistive technologies.

© ETSI 2021. All rights reserved

Læs klausulen i EN 301 549 version 3.2.1 [engelsk]
Where the software provides a user interface it shall expose the relationship that a user interface element has as a label for another element, or of being labelled by another element, using the services as described in clause 11.5.2.3, so that this information is programmatically determinable by assistive technologies.

© ETSI 2021. All rights reserved

Læs klausulen i EN 301 549 version 3.2.1 [engelsk]
Where the software provides a user interface it shall, by using the services as described in clause 11.5.2.3, make the relationship between a user interface element and any parent or children elements programmatically determinable by assistive technologies.

© ETSI 2021. All rights reserved

Læs klausulen i EN 301 549 version 3.2.1 [engelsk]
Where the software provides a user interface it shall, by using the services as described in clause 11.5.2.3, make the text contents, text attributes, and the boundary of text rendered to the screen programmatically determinable by assistive technologies.

© ETSI 2021. All rights reserved

Læs klausulen i EN 301 549 version 3.2.1 [engelsk]
Where the software provides a user interface it shall, by using the services as described in clause 11.5.2.3, make a list of available actions that can be executed on a user interface element, programmatically determinable by assistive technologies.

© ETSI 2021. All rights reserved

Læs klausulen i EN 301 549 version 3.2.1 [engelsk]
Where permitted by security requirements, software that provides a user interface shall, by using the services as described in clause 11.5.2.3, allow the programmatic execution of the actions exposed according to clause 11.5.2.11 by assistive technologies.

NOTE 1: In some cases the security requirements imposed on a software product may forbid external software from interfering with the ICT product. Examples of systems under strict security requirements are systems dealing with intelligence activities, cryptologic activities related to national security, command and control of military forces.

NOTE 2: Assistive technologies may be required to maintain the same level of security as the standard input mechanisms supported by the platform.

© ETSI 2021. All rights reserved

Læs klausulen i EN 301 549 version 3.2.1 [engelsk]
Where software provides a user interface it shall, by using the services as described in clause 11.5.2.3, make information and mechanisms necessary to track focus, text insertion point, and selection attributes of user interface elements programmatically determinable by assistive technologies.

© ETSI 2021. All rights reserved

Læs klausulen i EN 301 549 version 3.2.1 [engelsk]
Where permitted by security requirements, software that provides a user interface shall, by using the services as described in clause 11.5.2.3, allow assistive technologies to programmatically modify focus, text insertion point, and selection attributes of user interface elements where the user can modify these items.

NOTE 1: In some cases the security requirements imposed on a software product may forbid external software from interfering with the ICT product and so this requirement would not apply. Examples of systems under strict security requirements are systems dealing with intelligence activities, cryptologic activities related to national security, command and control of military forces.

NOTE 2: Assistive technologies may be required to maintain the same level of security as the standard input mechanisms supported by the platform.

© ETSI 2021. All rights reserved

Læs klausulen i EN 301 549 version 3.2.1 [engelsk]
Where software provides a user interface it shall, by using the services as described in clause 11.5.2.3, notify assistive technologies about changes in those programmatically determinable attributes of user interface elements that are referenced in requirements 11.5.2.5 to 11.5.2.11 and 11.5.2.13.

© ETSI 2021. All rights reserved

Læs klausulen i EN 301 549 version 3.2.1 [engelsk]
Where permitted by security requirements, software that provides a user interface shall, by using the services as described in clause 11.5.2.3, allow assistive technologies to programmatically modify states and properties of user interface elements, where the user can modify these items.

NOTE 1: In some cases the security requirements imposed on a software product may forbid external software from interfering with the ICT product and so this requirement would not apply. Examples of systems under strict security requirements are systems dealing with intelligence activities, cryptologic activities related to national security, command and control of military forces.

NOTE 2: Assistive technologies may be required to maintain the same level of security as the standard input mechanisms supported by the platform.

© ETSI 2021. All rights reserved

Læs klausulen i EN 301 549 version 3.2.1 [engelsk]
Where permitted by security requirements, software that provides a user interface shall, by using the services as described in clause 11.5.2.3, allow assistive technologies to modify values and text of user interface elements using the input methods of the platform, where a user can modify these items without the use of assistive technology.

NOTE 1: In some cases the security requirements imposed on a software product may forbid external software from interfering with the ICT product and so this requirement would not apply. Examples of systems under strict security requirements are systems dealing with intelligence activities, cryptologic activities related to national security, command and control of military forces.

NOTE 2: Assistive technologies may be required to maintain the same level of security as the standard input mechanisms supported by the platform.

© ETSI 2021. All rights reserved

Læs klausulen i EN 301 549 version 3.2.1 [engelsk]
Where software provides a user interface it shall not disrupt those documented accessibility features that are defined in platform documentation except when requested to do so by the user during the operation of the software.

© ETSI 2021. All rights reserved

Læs klausulen i EN 301 549 version 3.2.1 [engelsk]

Software

Krav for websteder og mobilapplikationer

Krav særligt for mobilapplikationer

11.1.2.1.2.1 Pre-recorded audio-only (closed functionality)

11.1.2.1.2.2 Pre-recorded video-only (closed functionality)

Kontakt

Digitaliseringsstyrelsen

Genveje

Ofte besøgte sider

Digitaliseringsministeriet

Software

Krav for websteder og mobilapplikationer

11.7 User preferences

11.8.1 Content technology

11.8.2 Accessible content creation

11.8.3 Preservation of accessibility information in transformations

11.8.4 Repair assistance

11.8.5 Templates

Krav særligt for mobilapplikationer

11.1.1.1.1 Non-text content (open functionality)

11.1.1.1.2 Non-text content (closed functionality)

11.1.2.1.1 Audio-only and video-only (pre-recorded - open functionality)

11.1.2.1.2 Audio-only and video-only (pre-recorded - closed functionality)

11.1.2.2 Captions (pre- recorded)

11.1.2.3.1 Audio description or media alternative (pre-recorded - open functionality)

11.1.2.3.2 Audio description or media alternative (pre-recorded - closed functionality)

11.1.2.5 Audio description (pre-recorded)

11.1.3.1.1 Info and relationships (open functionality)

11.1.3.2.1 Meaningful sequence (open functionality)

11.1.3.3 Sensory characteristics

11.1.3.4 Orientation

11.1.3.5.1 Identify input purpose (open functionality)

11.1.3.5.2 Identify input purpose (closed functionality)

11.1.4.1 Use of colour

11.1.4.2 Audio control

11.1.4.3 Contrast (minimum)

11.1.4.4.1 Resize text (open functionality)

11.1.4.4.2 Resize text (closed functionality)

11.1.4.5.1 Images of text (open functionality)

11.1.4.5.2 Images of text (closed functionality)

11.1.4.10 Reflow

11.1.4.11 Non-text contrast

11.1.4.12 Text spacing

11.1.4.13 Content on hover or focus

11.2.1.1.1 Keyboard (open functionality)

11.2.1.1.2 Keyboard (closed functionality)

11.2.1.2 No keyboard trap

11.2.1.4.1 Character key shortcuts (open functionality)

11.2.1.4.2 Character key shortcuts (closed functionality)

11.2.2.1 Timing adjustable

11.2.2.2 Pause, stop, hide

11.2.3.1 Three flashes or below threshold

11.2.4.3 Focus order

11.2.4.4 Link purpose (in context)

11.2.4.6 Headings and labels

11.2.4.7 Focus visible

11.2.5.1 Pointer gestures

11.2.5.2 Pointer cancellation

11.2.5.3.1 Label in name (open functionality)

11.2.5.4 Motion actuation

11.3.1.1.1 Language of software (open functionality)

11.3.1.1.2 Language of software (closed functionality)

11.3.2.1 On focus

11.3.2.2 On input

11.3.3.1.1 Error identification (open functionality)

11.3.3.1.2 Error Identification (closed functionality)

11.3.3.2 Labels or instructions

11.3.3.3 Error suggestion

11.3.3.4 Error prevention (legal, financial, data)

11.4.1.1.1 Parsing (open functionality)

11.4.1.2.1 Name, role, value (open functionality)

11.4.1.3.1 Status messages (open functionality)

11.5.2.3 Use of accessibility services

11.5.2.5 Object information

11.5.2.6 Row, column, and headers

11.5.2.7 Values

11.5.2.8 Label relationships

11.5.2.9 Parent-child relationships

11.5.2.10 Text

11.5.2.11 List of available actions

11.5.2.12 Execution of available actions

11.5.2.13 Tracking of focus and selection attributes

11.5.2.14 Modification of focus and selection attributes

11.5.2.15 Change notification

11.5.2.16 Modifications of states and properties

11.5.2.17 Modifications of values and text

11.6.2 No disruption of accessibility features

Kontakt

Digitaliseringsstyrelsen

Genveje