Text input test scenarios
These test scenarios are designed to be human readable by using Gherkin syntax. Almost all of them are automated behind the scenes using JavaScript and Playwright, which you can see in the GitHub repo.
Sections: the scenarios are grouped by the same themes as the accessibility requirements in the component documentation, so each section here matches a section there.
Tags: marked by an @ symbol, tags are a
way to group related tests. For example, by component name, whether
it's an automated or manual test, and the WCAG level and success
criterion number.
Steps: every scenario is written with the same shared set of Given, When and Then steps. See the full list of test steps for what each one does.
View accessibility requirements
Adaptability
View accessibility requirements: Adaptability
@textInput @adaptability Feature: Text Input — Adaptability Helping people by honouring user preferences and by allowing adaptations to content presentation and time limits User story: As a person who needs to adjust the way content is presented, or to adjust timings I want components that my tools can interpret and adjust so that I can navigate, understand, and operate the interface reliably using the technology that supports me. Background: Given I load the sample "http://localhost:8081/text-input/examples/default" # ---------------------------------------------------------------------------- # Perceivable # ---------------------------------------------------------------------------- @1.3.4 @aa @automatic Rule: 1.3.4 Orientation, Level AA Scenario Outline: Content is not restricted to a single orientation, unless it's essential When I switch to landscape mode And I view the rendered "<element>" Then it should not lose any content or functionality Examples: | element | | .tl-text-input label | | .tl-text-input input | @1.4.4 @aa @automatic Rule: 1.4.4 Resize Text, Level AA Scenario Outline: Text can scale up to 200% without loss of content or functionality When I zoom in the browser to 200% And I view the rendered "<element>" Then it should not lose any content or functionality Examples: | element | | .tl-text-input label | | .tl-text-input input | @1.4.10 @aa @automatic Rule: 1.4.10 Reflow, Level AA Scenario: Content reflows without horizontal scrolling at 320px wide When I view the rendered '.tl-text-input' And I set the viewport to 320px wide Then it should reflow without requiring horizontal scrolling @1.4.12 @aa @automatic Rule: 1.4.12 Text Spacing, Level AA Scenario: Line, letter and word spacing can be increased without a loss of content When I view the rendered '.tl-text-input' And I increase the line height to 1.5 times the font size And I increase the spacing following paragraphs to 2 times the font size And I increase the letter spacing to 0.12 times the font size And I increase the word spacing to 0.16 times the font size Then it should not lose any content or functionality @1.4.8 @aaa @automatic Rule: 1.4.8 Visual Presentation, Level AAA Scenario: Content adjusts as expected when people apply their own colour, width, alignment, spacing and size preferences When I view the rendered '.tl-text-input' And I apply a custom foreground and background colour using a user stylesheet And I apply a custom max-width using a user stylesheet And I apply a custom text-alignment using a user stylesheet And I apply a custom line height using a user stylesheet And I apply a custom font size of 200% using a user stylesheet Then it should not lose any content or functionality @recommendation @automatic Rule: Recommendation Scenario: Content and information remains visible and understandable when using high contrast themes When I enable "forced colors" mode And I view the rendered '.tl-text-input' Then it should not lose any content or functionalityFeature: Text Input — Adaptability
Helping people by honouring user preferences and by allowing adaptations to content presentation and time limits
User story:
As a person who needs to adjust the way content is presented, or to adjust timings I want components that my tools can interpret and adjust so that I can navigate, understand, and operate the interface reliably using the technology that supports me.
Background:
Given I load the sample "https://tetralogical.com/resources/accessible-components-library/text-input/examples/default.html"
1.3.4 Orientation
Rule: 1.3.4 Orientation, Level AA
Scenario Outline: Content is not restricted to a single orientation, unless it's essential
When I switch to landscape mode
And I view the rendered "<element>"
Then it should not lose any content or functionality
Examples:
| element |
|---|
| .tl-text-input label |
| .tl-text-input input |
1.4.4 Resize Text
Rule: 1.4.4 Resize Text, Level AA
Scenario Outline: Text can scale up to 200% without loss of content or functionality
When I zoom in the browser to 200%
And I view the rendered "<element>"
Then it should not lose any content or functionality
Examples:
| element |
|---|
| .tl-text-input label |
| .tl-text-input input |
1.4.10 Reflow
Rule: 1.4.10 Reflow, Level AA
Scenario: Content reflows without horizontal scrolling at 320px wide
When I view the rendered '.tl-text-input'
And I set the viewport to 320px wide
Then it should reflow without requiring horizontal scrolling
1.4.12 Text Spacing
Rule: 1.4.12 Text Spacing, Level AA
Scenario: Line, letter and word spacing can be increased without a loss of content
When I view the rendered '.tl-text-input'
And I increase the line height to 1.5 times the font size
And I increase the spacing following paragraphs to 2 times the font size
And I increase the letter spacing to 0.12 times the font size
And I increase the word spacing to 0.16 times the font size
Then it should not lose any content or functionality
1.4.8 Visual Presentation
Rule: 1.4.8 Visual Presentation, Level AAA
Scenario: Content adjusts as expected when people apply their own colour, width, alignment, spacing and size preferences
When I view the rendered '.tl-text-input'
And I apply a custom foreground and background colour using a user stylesheet
And I apply a custom max-width using a user stylesheet
And I apply a custom text-alignment using a user stylesheet
And I apply a custom line height using a user stylesheet
And I apply a custom font size of 200% using a user stylesheet
Then it should not lose any content or functionality
Recommendations
Rule: Recommendation
Scenario: Content and information remains visible and understandable when using high contrast themes
When I enable "forced colors" mode
And I view the rendered '.tl-text-input'
Then it should not lose any content or functionality
Animation and movement
View accessibility requirements: Animation and movement
@textInput @animation-and-movement Feature: Text Input — Animation and movement Helping people to limit animation or reduce motion within content No component-specific requirementsFeature: Text Input — Animation and movement
Helping people to limit animation or reduce motion within content
No component-specific requirements
Assistive technologies and semantics
View accessibility requirements: Assistive technologies and semantics
@textInput @assistive-technologies-and-semantics Feature: Text Input — Assistive technologies and semantics Helping people who use a screen reader or other assistive tech by using appropriate code User story: As a person who uses assistive technology I want components that use semantic markup, roles, and states that my tools can interpret so that I can navigate, understand, and operate the interface reliably. Background: Given I load the sample "http://localhost:8081/text-input/examples/default" # ---------------------------------------------------------------------------- # Perceivable # ---------------------------------------------------------------------------- @1.3.1 @a @automatic Rule: 1.3.1 Info and Relationships, Level A Scenario: The hint text is programmatically associated with the text input using aria-describedby When I inspect ".tl-text-input input" in the DOM Then it should have the attribute "aria-describedby" with the value "input-1-hint" @1.3.1 @a @automatic Rule: 1.3.1 Info and Relationships, Level A Scenario: A text input without hint text has no aria-describedby pointing at a hint Given I load the sample "http://localhost:8081/text-input/examples/without-hint" When I inspect ".tl-text-input input" in the DOM Then it should not have the attribute "aria-describedby" @1.3.1 @a @automatic Rule: 1.3.1 Info and Relationships, Level A Scenario: The hint referenced by the text input's aria-describedby is present in the DOM When I inspect ".tl-text-input #input-1-hint" in the DOM Then it should use the tag "p" @1.3.2 @a @automatic Rule: 1.3.2 Meaningful Sequence, Level A Scenario: The order of content in the HTML matches the reading order When I inspect ".tl-text-input input" in the DOM Then it is positioned after the ".tl-text-input label" element in the DOM @1.3.5 @aa @automatic Rule: 1.3.5 Identify Input Purpose, Level AA Scenario: A text input collecting personal information has an appropriate autocomplete attribute When I inspect ".tl-text-input input" in the DOM Then it should have the attribute "autocomplete" with the value "name" # ---------------------------------------------------------------------------- # Operable # ---------------------------------------------------------------------------- @2.5.3 @a @automatic Rule: 2.5.3 Label in Name, Level A Scenario: The text input has an accessible name which contains its visible label When I view the rendered ".tl-text-input input" Then it should have an accessible name which contains the visible label "Full name" # ---------------------------------------------------------------------------- # Robust # ---------------------------------------------------------------------------- @4.1.2 @a @automatic Rule: 4.1.2 Name, Role, Value, Level A Scenario: The text input has an accessible name When I inspect ".tl-text-input input" in the DOM Then it should have an accessible name And its accessible name should be "Full name" @4.1.2 @a @automatic Rule: 4.1.2 Name, Role, Value, Level A Scenario: The text input has the correct accessible role When I inspect ".tl-text-input input" in the DOM Then it should have an accessible role of "textbox" @recommendation @automatic Rule: Recommendation Scenario Outline: The component uses native HTML elements for the input and its label When I inspect "<element>" in the DOM Then it should use the tag "<tag>" Examples: | element | tag | | .tl-text-input label | label | | .tl-text-input input | input | @recommendation @automatic Rule: Recommendation Scenario Outline: The label is programmatically associated with the input using the for and id attributes When I inspect "<element>" in the DOM Then it should have the attribute "<attribute>" with the value "<value>" Examples: | element | attribute | value | | .tl-text-input label | for | input-1 | | .tl-text-input input | id | input-1 | @recommendation @automatic Rule: Recommendation Scenario: When the text input has an error, the invalid state is conveyed using aria-invalid Given I load the sample "http://localhost:8081/text-input/examples/error" When I inspect ".tl-text-input input" in the DOM Then it should have the attribute "aria-invalid" with the value "true" @recommendation @automatic Rule: Recommendation Scenario: Markup can be parsed without errors When I inspect ".tl-text-input" in the DOM Then it should use valid HTML with no parsing errorsFeature: Text Input — Assistive technologies and semantics
Helping people who use a screen reader or other assistive tech by using appropriate code
User story:
As a person who uses assistive technology I want components that use semantic markup, roles, and states that my tools can interpret so that I can navigate, understand, and operate the interface reliably.
Background:
Given I load the sample "https://tetralogical.com/resources/accessible-components-library/text-input/examples/default.html"
1.3.1 Info and Relationships
Rule: 1.3.1 Info and Relationships, Level A
Scenario: The hint text is programmatically associated with the text input using aria-describedby
When I inspect ".tl-text-input input" in the DOM
Then it should have the attribute "aria-describedby" with the value "input-1-hint"
Rule: 1.3.1 Info and Relationships, Level A
Scenario: A text input without hint text has no aria-describedby pointing at a hint
Given I load the sample "https://tetralogical.com/resources/accessible-components-library/text-input/examples/without-hint.html"
When I inspect ".tl-text-input input" in the DOM
Then it should not have the attribute "aria-describedby"
Rule: 1.3.1 Info and Relationships, Level A
Scenario: The hint referenced by the text input's aria-describedby is present in the DOM
When I inspect ".tl-text-input #input-1-hint" in the DOM
Then it should use the tag "p"
1.3.2 Meaningful Sequence
Rule: 1.3.2 Meaningful Sequence, Level A
Scenario: The order of content in the HTML matches the reading order
When I inspect ".tl-text-input input" in the DOM
Then it is positioned after the ".tl-text-input label" element in the DOM
1.3.5 Identify Input Purpose
Rule: 1.3.5 Identify Input Purpose, Level AA
Scenario: A text input collecting personal information has an appropriate autocomplete attribute
When I inspect ".tl-text-input input" in the DOM
Then it should have the attribute "autocomplete" with the value "name"
2.5.3 Label in Name
Rule: 2.5.3 Label in Name, Level A
Scenario: The text input has an accessible name which contains its visible label
When I view the rendered ".tl-text-input input"
Then it should have an accessible name which contains the visible label "Full name"
4.1.2 Name, Role, Value
Rule: 4.1.2 Name, Role, Value, Level A
Scenario: The text input has an accessible name
When I inspect ".tl-text-input input" in the DOM
Then it should have an accessible name
And its accessible name should be "Full name"
Rule: 4.1.2 Name, Role, Value, Level A
Scenario: The text input has the correct accessible role
When I inspect ".tl-text-input input" in the DOM
Then it should have an accessible role of "textbox"
Recommendations
Rule: Recommendation
Scenario Outline: The component uses native HTML elements for the input and its label
When I inspect "<element>" in the DOM
Then it should use the tag "<tag>"
Examples:
| element | tag |
|---|---|
| .tl-text-input label | label |
| .tl-text-input input | input |
Rule: Recommendation
Scenario Outline: The label is programmatically associated with the input using the for and id attributes
When I inspect "<element>" in the DOM
Then it should have the attribute "<attribute>" with the value "<value>"
Examples:
| element | attribute | value |
|---|---|---|
| .tl-text-input label | for | input-1 |
| .tl-text-input input | id | input-1 |
Rule: Recommendation
Scenario: When the text input has an error, the invalid state is conveyed using aria-invalid
Given I load the sample "https://tetralogical.com/resources/accessible-components-library/text-input/examples/error.html"
When I inspect ".tl-text-input input" in the DOM
Then it should have the attribute "aria-invalid" with the value "true"
Rule: Recommendation
Scenario: Markup can be parsed without errors
When I inspect ".tl-text-input" in the DOM
Then it should use valid HTML with no parsing errors
Colour and contrast
View accessibility requirements: Colour and contrast
@textInput @colour-and-contrast Feature: Text Input — Colour and contrast Helping people who struggle with colour perception or low vision User story: As a person with low vision or colour vision deficiency I want components with sufficient contrast and that don't rely solely on colour so that I can perceive and understand all content and interface elements. Background: Given I load the sample "http://localhost:8081/text-input/examples/default" # ---------------------------------------------------------------------------- # Perceivable # ---------------------------------------------------------------------------- @1.4.1 @a @automatic Rule: 1.4.1 Use of Color, Level A Scenario: Colour alone is not used to identify a text input in error Given I load the sample "http://localhost:8081/text-input/examples/error" When I inspect ".tl-text-input .error-message" in the Accessibility Tree Then it should contain static text, not an image Scenario: The error message is associated with the text input Given I load the sample "http://localhost:8081/text-input/examples/error" When I inspect "#input-1" in the DOM Then it should have the attribute "aria-describedby" with the value "input-1-hint input-1-error" And it should have the attribute "aria-invalid" with the value "true" @1.4.3 @aa @automatic Rule: 1.4.3 Contrast (Minimum), Level AA Scenario Outline: Text content has a contrast ratio of at least 4.5:1 against its background When I view the rendered "<element>" Then its text should have a contrast ratio of '4.5:1' against its background Examples: | element | | .tl-text-input label | | .tl-text-input input | @1.4.3 @aa @automatic Rule: 1.4.3 Contrast (Minimum), Level AA Scenario: The error message text has a contrast ratio of at least 4.5:1 against its background Given I load the sample "http://localhost:8081/text-input/examples/error" When I view the rendered ".tl-text-input .error-message" Then its text should have a contrast ratio of '4.5:1' against its background @1.4.3 @aa @automatic Rule: 1.4.3 Contrast (Minimum), Level AA Scenario: The hint text has a contrast ratio of at least 4.5:1 against its background When I view the rendered ".tl-text-input .hint-text" Then its text should have a contrast ratio of '4.5:1' against its background @1.4.11 @aa @automatic Rule: 1.4.11 Non-text Contrast, Level AA Scenario: The custom focus indicator has a contrast ratio of at least 3:1 against the background When I focus ".tl-text-input input" using a keyboard Then it should have a visible focus indicator And the focus indicator should have a contrast ratio of 3:1 against its background @1.4.6 @aaa @automatic Rule: 1.4.6 Contrast (Enhanced), Level AAA Scenario Outline: Text content has a contrast ratio of at least 7:1 against its background When I view the rendered "<element>" Then its text should have a contrast ratio of '7:1' against its background Examples: | element | | .tl-text-input label | | .tl-text-input input | @1.4.6 @aaa @automatic Rule: 1.4.6 Contrast (Enhanced), Level AAA Scenario: The hint text has a contrast ratio of at least 7:1 against its background When I view the rendered ".tl-text-input .hint-text" Then its text should have a contrast ratio of '7:1' against its backgroundFeature: Text Input — Colour and contrast
Helping people who struggle with colour perception or low vision
User story:
As a person with low vision or colour vision deficiency I want components with sufficient contrast and that don't rely solely on colour so that I can perceive and understand all content and interface elements.
Background:
Given I load the sample "https://tetralogical.com/resources/accessible-components-library/text-input/examples/default.html"
1.4.1 Use of Color
Rule: 1.4.1 Use of Color, Level A
Scenario: Colour alone is not used to identify a text input in error
Given I load the sample "https://tetralogical.com/resources/accessible-components-library/text-input/examples/error.html"
When I inspect ".tl-text-input .error-message" in the Accessibility Tree
Then it should contain static text, not an image
Scenario: The error message is associated with the text input
Given I load the sample "https://tetralogical.com/resources/accessible-components-library/text-input/examples/error.html"
When I inspect "#input-1" in the DOM
Then it should have the attribute "aria-describedby" with the value "input-1-hint input-1-error"
And it should have the attribute "aria-invalid" with the value "true"
1.4.3 Contrast (Minimum)
Rule: 1.4.3 Contrast (Minimum), Level AA
Scenario Outline: Text content has a contrast ratio of at least 4.5:1 against its background
When I view the rendered "<element>"
Then its text should have a contrast ratio of '4.5:1' against its background
Examples:
| element |
|---|
| .tl-text-input label |
| .tl-text-input input |
Rule: 1.4.3 Contrast (Minimum), Level AA
Scenario: The error message text has a contrast ratio of at least 4.5:1 against its background
Given I load the sample "https://tetralogical.com/resources/accessible-components-library/text-input/examples/error.html"
When I view the rendered ".tl-text-input .error-message"
Then its text should have a contrast ratio of '4.5:1' against its background
Rule: 1.4.3 Contrast (Minimum), Level AA
Scenario: The hint text has a contrast ratio of at least 4.5:1 against its background
When I view the rendered ".tl-text-input .hint-text"
Then its text should have a contrast ratio of '4.5:1' against its background
1.4.11 Non-text Contrast
Rule: 1.4.11 Non-text Contrast, Level AA
Scenario: The custom focus indicator has a contrast ratio of at least 3:1 against the background
When I focus ".tl-text-input input" using a keyboard
Then it should have a visible focus indicator
And the focus indicator should have a contrast ratio of 3:1 against its background
1.4.6 Contrast (Enhanced)
Rule: 1.4.6 Contrast (Enhanced), Level AAA
Scenario Outline: Text content has a contrast ratio of at least 7:1 against its background
When I view the rendered "<element>"
Then its text should have a contrast ratio of '7:1' against its background
Examples:
| element |
|---|
| .tl-text-input label |
| .tl-text-input input |
Rule: 1.4.6 Contrast (Enhanced), Level AAA
Scenario: The hint text has a contrast ratio of at least 7:1 against its background
When I view the rendered ".tl-text-input .hint-text"
Then its text should have a contrast ratio of '7:1' against its background
Consistency and predictability
View accessibility requirements: Consistency and predictability
@textInput @consistency-and-predictability Feature: Text Input — Consistency and predictability Helping people by keeping functionality consistent and predictable User story: As a person who benefits from consistent and predictable interfaces I want components that behave in expected ways and don't cause unexpected changes so that I can navigate and interact with confidence. Background: Given I load the sample "http://localhost:8081/text-input/examples/default" # ---------------------------------------------------------------------------- # Understandable # ---------------------------------------------------------------------------- @3.2.1 @a @automatic Rule: 3.2.1 On Focus, Level A Scenario: Receiving focus does not initiate a change of context When I focus ".tl-text-input input" using a keyboard Then it should NOT navigate to a new pageFeature: Text Input — Consistency and predictability
Helping people by keeping functionality consistent and predictable
User story:
As a person who benefits from consistent and predictable interfaces I want components that behave in expected ways and don't cause unexpected changes so that I can navigate and interact with confidence.
Background:
Given I load the sample "https://tetralogical.com/resources/accessible-components-library/text-input/examples/default.html"
3.2.1 On Focus
Rule: 3.2.1 On Focus, Level A
Scenario: Receiving focus does not initiate a change of context
When I focus ".tl-text-input input" using a keyboard
Then it should NOT navigate to a new page
Images and media
View accessibility requirements: Images and media
@textInput @images-and-media Feature: Text Input — Images and media Helping people to access (and remove distractions caused by) image, video and audio content User story: As a person who cannot see images I want appropriate text alternatives for images so that I can access the same information as everyone else. Background: Given I load the sample "http://localhost:8081/text-input/examples/default" # ---------------------------------------------------------------------------- # Perceivable # ---------------------------------------------------------------------------- @1.4.5 @aa @automatic Rule: 1.4.5 Images of Text, Level AA Scenario: Real text is used instead of images of text (except essential/logos) When I view the rendered '.tl-text-input' Then it should not contain any images @1.4.9 @aaa @automatic Rule: 1.4.9 Images of Text (No Exception), Level AAA Scenario: No images of text at all When I view the rendered '.tl-text-input' Then it should not contain any imagesFeature: Text Input — Images and media
Helping people to access (and remove distractions caused by) image, video and audio content
User story:
As a person who cannot see images I want appropriate text alternatives for images so that I can access the same information as everyone else.
Background:
Given I load the sample "https://tetralogical.com/resources/accessible-components-library/text-input/examples/default.html"
1.4.5 Images of Text
Rule: 1.4.5 Images of Text, Level AA
Scenario: Real text is used instead of images of text (except essential/logos)
When I view the rendered '.tl-text-input'
Then it should not contain any images
1.4.9 Images of Text (No Exception)
Rule: 1.4.9 Images of Text (No Exception), Level AAA
Scenario: No images of text at all
When I view the rendered '.tl-text-input'
Then it should not contain any images
Input assistance
View accessibility requirements: Input assistance
@textInput @input-assistance Feature: Text Input — Input assistance Helping people to complete forms, enter data and pass authentication User story: As a person who completes forms or enters data I want clear labels, helpful error messages, and accessible authentication so that I can successfully complete tasks without confusion or frustration. Background: Given I load the sample "http://localhost:8081/text-input/examples/default" # ---------------------------------------------------------------------------- # Understandable # ---------------------------------------------------------------------------- @3.3.2 @a @manual Rule: 3.3.2 Labels or Instructions, Level A Scenario: The persistent label makes the expected input clear When I view the rendered ".tl-text-input label" Then it should be easy to understand the expected input from the label textFeature: Text Input — Input assistance
Helping people to complete forms, enter data and pass authentication
User story:
As a person who completes forms or enters data I want clear labels, helpful error messages, and accessible authentication so that I can successfully complete tasks without confusion or frustration.
Background:
Given I load the sample "https://tetralogical.com/resources/accessible-components-library/text-input/examples/default.html"
3.3.2 Labels or Instructions
Rule: 3.3.2 Labels or Instructions, Level A
Scenario: The persistent label makes the expected input clear
When I view the rendered ".tl-text-input label"
Then it should be easy to understand the expected input from the label text
Keyboard
View accessibility requirements: Keyboard
@textInput @keyboard Feature: Text Input — Keyboard Helping people who use a keyboard User story: As a keyboard user I want components that follow a logical tab order and provide visible, predictable focus states so that I can move through the interface efficiently and operate every feature without using a mouse. Background: Given I load the sample "http://localhost:8081/text-input/examples/default" # ---------------------------------------------------------------------------- # Operable # ---------------------------------------------------------------------------- @2.1.1 @a @automatic Rule: 2.1.1 Keyboard, Level A Scenario: The text input is focusable using the Tab key When I focus ".tl-text-input input" using a keyboard Then ".tl-text-input input" should be focused @2.1.2 @a @automatic Rule: 2.1.2 No Keyboard Trap, Level A Scenario: The text input does not trap focus going forwards When I focus ".tl-text-input input" And I press the 'TAB' key once Then the focus should not be on a '.tl-text-input input' element @2.1.2 @a @automatic Rule: 2.1.2 No Keyboard Trap, Level A Scenario: The text input does not trap focus going backwards When I focus ".tl-text-input input" And I hold the 'SHIFT' key And I press the 'TAB' key once Then the focus should not be on a '.tl-text-input input' element @2.4.7 @aa @automatic Rule: 2.4.7 Focus Visible, Level AA Scenario: The text input has a visible focus indicator when it receives keyboard focus When I focus ".tl-text-input input" using a keyboard Then it should have a visible focus indicator @2.4.11 @aa @automatic Rule: 2.4.11 Focus Not Obscured (Minimum), Level AA Scenario: The text input is not fully hidden by other content when it receives keyboard focus When I focus ".tl-text-input input" using a keyboard Then it should have a visible focus indicator And its focus indicator should be at least partially visible @2.1.3 @aaa @automatic Rule: 2.1.3 Keyboard (No Exception), Level AAA Scenario: The text input is operable by keyboard with no exceptions When I focus ".tl-text-input input" using a keyboard Then ".tl-text-input input" should be focused @2.4.12 @aaa @automatic Rule: 2.4.12 Focus Not Obscured (Enhanced), Level AAA Scenario: Focus is not even partially hidden by other content When I focus ".tl-text-input input" using a keyboard Then it should have a visible focus indicator And its focus indicator should be fully visible @2.4.13 @aaa @automatic Rule: 2.4.13 Focus Appearance, Level AAA Scenario: The custom focus style has a solid 2 pixel thick perimeter, or equivalent, and a contrast ratio of at least 3:1 against the background When I focus ".tl-text-input input" using a keyboard Then it should have a visible focus indicator And the focus indicator should have a contrast ratio of 3:1 against its background And its focus indicator should have a minimum perimiter thickness of 2pxFeature: Text Input — Keyboard
Helping people who use a keyboard
User story:
As a keyboard user I want components that follow a logical tab order and provide visible, predictable focus states so that I can move through the interface efficiently and operate every feature without using a mouse.
Background:
Given I load the sample "https://tetralogical.com/resources/accessible-components-library/text-input/examples/default.html"
2.1.1 Keyboard
Rule: 2.1.1 Keyboard, Level A
Scenario: The text input is focusable using the Tab key
When I focus ".tl-text-input input" using a keyboard
Then ".tl-text-input input" should be focused
2.1.2 No Keyboard Trap
Rule: 2.1.2 No Keyboard Trap, Level A
Scenario: The text input does not trap focus going forwards
When I focus ".tl-text-input input"
And I press the 'TAB' key once
Then the focus should not be on a '.tl-text-input input' element
Rule: 2.1.2 No Keyboard Trap, Level A
Scenario: The text input does not trap focus going backwards
When I focus ".tl-text-input input"
And I hold the 'SHIFT' key
And I press the 'TAB' key once
Then the focus should not be on a '.tl-text-input input' element
2.4.7 Focus Visible
Rule: 2.4.7 Focus Visible, Level AA
Scenario: The text input has a visible focus indicator when it receives keyboard focus
When I focus ".tl-text-input input" using a keyboard
Then it should have a visible focus indicator
2.4.11 Focus Not Obscured (Minimum)
Rule: 2.4.11 Focus Not Obscured (Minimum), Level AA
Scenario: The text input is not fully hidden by other content when it receives keyboard focus
When I focus ".tl-text-input input" using a keyboard
Then it should have a visible focus indicator
And its focus indicator should be at least partially visible
2.1.3 Keyboard (No Exception)
Rule: 2.1.3 Keyboard (No Exception), Level AAA
Scenario: The text input is operable by keyboard with no exceptions
When I focus ".tl-text-input input" using a keyboard
Then ".tl-text-input input" should be focused
2.4.12 Focus Not Obscured (Enhanced)
Rule: 2.4.12 Focus Not Obscured (Enhanced), Level AAA
Scenario: Focus is not even partially hidden by other content
When I focus ".tl-text-input input" using a keyboard
Then it should have a visible focus indicator
And its focus indicator should be fully visible
2.4.13 Focus Appearance
Rule: 2.4.13 Focus Appearance, Level AAA
Scenario: The custom focus style has a solid 2 pixel thick perimeter, or equivalent, and a contrast ratio of at least 3:1 against the background
When I focus ".tl-text-input input" using a keyboard
Then it should have a visible focus indicator
And the focus indicator should have a contrast ratio of 3:1 against its background
And its focus indicator should have a minimum perimiter thickness of 2px
Pointer and touch
View accessibility requirements: Pointer and touch
@textInput @pointer-and-touch Feature: Text Input — Pointer and touch Helping people use single pointer or touch interactions User story: As a person using touch or pointer input I want components with accessible gestures, adequate target sizes, and predictable interactions so that I can accurately interact with all functionality. Background: Given I load the sample "http://localhost:8081/text-input/examples/default" # ---------------------------------------------------------------------------- # Operable # ---------------------------------------------------------------------------- @2.5.8 @aa @automatic Rule: 2.5.8 Target Size (Minimum), Level AA Scenario: The text input has a target area size and spacing of at least 24 by 24 pixels When I view the rendered ".tl-text-input input" Then it should have a width and height of at least 24px @2.5.5 @aaa @automatic Rule: 2.5.5 Target Size (Enhanced), Level AAA Scenario: The text input has a target area size and spacing of at least 44 by 44 pixels When I view the rendered ".tl-text-input input" Then it should have a width and height of at least 44pxFeature: Text Input — Pointer and touch
Helping people use single pointer or touch interactions
User story:
As a person using touch or pointer input I want components with accessible gestures, adequate target sizes, and predictable interactions so that I can accurately interact with all functionality.
Background:
Given I load the sample "https://tetralogical.com/resources/accessible-components-library/text-input/examples/default.html"
2.5.8 Target Size (Minimum)
Rule: 2.5.8 Target Size (Minimum), Level AA
Scenario: The text input has a target area size and spacing of at least 24 by 24 pixels
When I view the rendered ".tl-text-input input"
Then it should have a width and height of at least 24px
2.5.5 Target Size (Enhanced)
Rule: 2.5.5 Target Size (Enhanced), Level AAA
Scenario: The text input has a target area size and spacing of at least 44 by 44 pixels
When I view the rendered ".tl-text-input input"
Then it should have a width and height of at least 44px
Text comprehension
View accessibility requirements: Text comprehension
@textInput @text-comprehension Feature: Text Input — Text comprehension Helping people to read and understand text content User story: As a person who may struggle with complex language or symbols I want optional fields to be marked in plain words so that I can complete the form without guessing what a symbol means. Background: Given I load the sample "http://localhost:8081/text-input/examples/default" # ---------------------------------------------------------------------------- # Understandable # ---------------------------------------------------------------------------- @recommendation @automatic Rule: Recommendation Scenario: An optional text input has the text "(optional)" in its label Given I load the sample "http://localhost:8081/text-input/examples/without-hint" When I inspect ".tl-text-input label" in the DOM Then it should contain the text "(optional)" @recommendation @automatic Rule: Recommendation Scenario: An asterisk is not used to indicate that a text input is required When I inspect ".tl-text-input" in the DOM Then it should not contain the text "*"Feature: Text Input — Text comprehension
Helping people to read and understand text content
User story:
As a person who may struggle with complex language or symbols I want optional fields to be marked in plain words so that I can complete the form without guessing what a symbol means.
Background:
Given I load the sample "https://tetralogical.com/resources/accessible-components-library/text-input/examples/default.html"
Recommendations
Rule: Recommendation
Scenario: An optional text input has the text "(optional)" in its label
Given I load the sample "https://tetralogical.com/resources/accessible-components-library/text-input/examples/without-hint.html"
When I inspect ".tl-text-input label" in the DOM
Then it should contain the text "(optional)"
Rule: Recommendation
Scenario: An asterisk is not used to indicate that a text input is required
When I inspect ".tl-text-input" in the DOM
Then it should not contain the text "*"