diff --git a/Templates/BAWG-Tmpl-01.dwt b/Templates/BAWG-Tmpl-01.dwt index bc200ece..583ccaf7 100644 --- a/Templates/BAWG-Tmpl-01.dwt +++ b/Templates/BAWG-Tmpl-01.dwt @@ -85,34 +85,51 @@
-

Test Case Title

+

Image - text equivalent in alt attribute

Test Case Summary

Test Case ID

TC05-001-fail ([ParentBaseline-IncrementalTC#-Pass/Fail/DNA])

Test Case Description

[Brief description of the code sample/issue to be tested. Include and detail about why this specific test case is necessary] - here is wehre we need to provide very specific guidance on description and intent.

Applicable ICT Baseline

-

6. Images ([Baseline Name linked to URL])

-

- Meaningful Images (Test Case Heading)

-
00.0 Test Procedure for Form Name
- - - - <If the image is meaningful...> - +

6.1 Test Procedure for Meaningful Images
+ Baseline Test ID: 6.1-MeaningfulImage

+ + +

Identify Content

+ Identify any image that conveys information (include images of text; functional images used to initiate action, convey meaning, or prompting a response; image maps, etc.). -
Test Results
+ +

Test Instructions

- - -
    -
  • <If any of the above checks fail...>
  • -
- + + +
    +
  1. Check that the combination of the accessible name and accessible description is not empty. [SC 1.1.1]
  2. +
  3. Check that the non-empty combination of accessible name and accessible description provides an equivalent description. Numerous attributes contribute to the computation of the accessible name and accessible description. Refer to HTML Accessibility API Mappings 1.0 for img. [SC 1.1.1] +
      +
    1. Descriptions of the image that are provided by page content must be programmatically associated.
    2. +
    3. When an image is updated to convey a new meaning, check that its text alternative is updated at the same time. [SCs 1.1.1 and 4.1.2]
    4. +
    +
  4. +
  5. Check that the ARIA role is NOT “presentation”.
  6. +
  7. Check that the ARIA role is NOT “none”.
  8. +
  9. Check that aria-hidden is NOT set to “true”.
  10. +
+ + + +

Test Results

+ + + +
    +
  • If any of the above checks fail, then Baseline Test 6.1-MeaningfulImage fails results
+ + -

Applicable WCAG/508 Requirement

+

Applicable WCAG/508 Requirement

  • diff --git a/docs/testCaseTemplate.html b/docs/testCaseTemplate.html index 350355d0..c92c05a7 100644 --- a/docs/testCaseTemplate.html +++ b/docs/testCaseTemplate.html @@ -81,8 +81,14 @@

    Test Case ID

    Test Case Description

    [Brief description of the code sample/issue to be tested. Include and detail about why this specific test case is necessary] - here is wehre we need to provide very specific guidance on description and intent

    Applicable ICT Baseline

    -

    [Baseline Name linked to URL]

    -

    [Baseline text with how to test]

    +

    [Baseline Test Procedure Statement linked to URL (6.1 Test Procedure for Meaningful Images) ]

    +

    [Baseline Test ID (Baseline Test ID: 6.1-MeaningfulImage) ]

    +

    Identify Content

    +

    [Baseline steps for identifying content]

    +

    Test Instructions

    +

    [Baseline steps describing test instructions]

    +

    Test Results

    +

    [Test results (If any of the above checks fail, then Baseline Test 6.1-MeaningfulImage fails)]

    Applicable WCAG/508 Requirement

    [WCAG/508 Req linked to URL]

    [WCAG SC/508 Req text]

    diff --git a/docs/testcases.html b/docs/testcases.html index 1e7fe1f7..e4ade697 100644 --- a/docs/testcases.html +++ b/docs/testcases.html @@ -76,6 +76,11 @@

    Placeholder Index

    Test Case documents are organized by Baseline Test (each seving as a Test Scenario or general "functional requirement" for testing), which inculde multiple Test Cases. Will need to develop a Test Scenario template to summarize Test Scenario purpose and subordinate Test Cases.

      +
    • 5. Changing Content + +
    • 6. Images
        diff --git a/docs/testcases/TC05-001-fail.html b/docs/testcases/TC05-001-fail.html index 3806ba77..2b633ada 100644 --- a/docs/testcases/TC05-001-fail.html +++ b/docs/testcases/TC05-001-fail.html @@ -92,61 +92,67 @@

        Test Case ID

        Test Case Description

        The aria-live politeness setting is used to set the priority with which screen readers should announce updates to designated live regions. The options are off, polite and assertive. With the exceptions of the ARIA roles of alert, log, and status (with default option settings of assertive, polite, and polite respectively), the default aria-live option is off. For any live region meant to convey meaningful information to assistive technology, the off setting, being the same as the omission of the live region altogether, would represent a failure of accessibility. The code sample presents aria-live='off'. A successful test should identify a failure against Baseline Test 5.1-ChangeContent.

        Applicable ICT Baseline

        -

        05. Changing Content

        -

        Visual and programmatically associated changes in content

        -
        5.1 Test Procedure for Changes in Content
        - - - -

        Baseline Test ID: 5.1-ChangeContent

        - -
        Identify Content
        -

        Identify changes in presented content (both user driven and automatic). Examples include changes to images, navigation trees, data table sort controls, automatic information updates, form elements, revealed content, etc.

        -
          -
        • It may be necessary to use the mouse to determine whether state changes occur on hover or on click.
        • -
        • Depending on the component, a change of state may be triggered by various actions, such as changing values or states of other components, toggling a function, entering data in the component, mouseover, etc.
        • -
        -
        4.1.2 Name, Role, Value
        -
          -
        1. Check that the page provides a notification of the change in content programmatically. [SC 4.1.2] -
            -
          1. Programmatic event notifications include alert dialogs, focus shifts to the content that changed, and ARIA live regions.
          2. -
          -
        2. -
        3. For each change in content, check that the combination of name, role, state, and value of the changed content is accurate. [SC 4.1.2] -
            -
          1. Name: the name is accurate after a change. - -
          2. -
          3. Role: the role accurately describes the purpose of the element after a change, if applicable. -
              -
            • Consider ARIA role, element type, and other descriptive text.
            • -
            -
          4. -
          5. State: the state of the element is accurate after a change, if applicable -
              -
            • Evaluate ARIA and element-specific attributes (e.g., <option selected=”true”>)
            • -
            -
          6. -
          7. Value: the value is updated after a change, if applicable.
          8. -
          -
        4. -
        - +

        5.1 Test Procedure for Changes in Content
        +
        + Baseline Test ID: 5.1-ChangeContent
        +

        + + +

        Identify Content

        + +

        Identify changes in presented content (both user driven and automatic). Examples include changes to images, navigation trees, data table sort controls, automatic information updates, form elements, revealed content, etc.

        +
          +
        • It may be necessary to use the mouse to determine whether state changes occur on hover or on click.
        • +
        • Depending on the component, a change of state may be triggered by various actions, such as changing values or states of other components, toggling a function, entering data in the component, mouseover, etc.
        • +
        + -
        Test Results
        + +

        Test Instructions

        - - -
          -
        • If any of the above checks fail, then Baseline Test 5.1-ChangeContent fails.
        • -
        - + + +
          +
        1. Check that the page provides a notification of the change in content programmatically. [SC 4.1.2] +
            +
          • Programmatic event notifications include alert dialogs, focus shifts to the content that changed, and ARIA live regions.
          • +
          +
        2. +
        3. For each change in content, check that the combination of name, role, state, and value of the changed content is accurate. [SC 4.1.2] +
            +
          • Name: the name is accurate after a change. + +
          • +
          • Role: the role accurately describes the purpose of the element after a change, if applicable. +
              +
            • Consider ARIA role, element type, and other descriptive text.
            • +
            +
          • +
          • State: the state of the element is accurate after a change, if applicable +
              +
            • Evaluate ARIA and element-specific attributes (e.g., <option selected=”true”>)
            • +
            +
          • +
          • Value: the value is updated after a change, if applicable.
          • +
          +
        4. +
        + + + +

        Test Results

        + + + +
          +
        • If any of the above checks fail, then Baseline Test 5.1-ChangeContent fails.
        + + -

        Applicable WCAG/508 Requirement

        +

        Applicable WCAG/508 Requirement

        • WCAG2 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.
        • @@ -167,7 +173,7 @@

          Expected Baseline Result

          - Fail + FAIL

          @@ -261,8 +267,8 @@

          Test Steps

          5 - If any of the above checks fail, then Baseline Test 5.1-ChangeContent fails. - Test step 3 fails due to the absence of the text change being conveyed programmatically in any way and therefore Baseline Test 5.1-ChangeContent fails. + Determine whether any checks fail according to the 5.1 Test Procedure for Changes in Content test instructions. + This test fails due to the absence of the text change being conveyed programmatically and therefore Baseline Test ID 5.1-ChangeContent fails. diff --git a/docs/testcases/TC10-001-fail.html b/docs/testcases/TC10-001-fail.html index 4c1a3697..4809a0f0 100644 --- a/docs/testcases/TC10-001-fail.html +++ b/docs/testcases/TC10-001-fail.html @@ -92,44 +92,48 @@

          Test Case ID

          Test Case Description

          Detect attributes that would contribute to the accessible name and accessible description computation and calculate the text alternative for the input element. The code sample data does not include attributes that contribute to accessible name or accessible description output. A successful test should identify a failure against Baseline Test 10.1 FormName.

          Applicable ICT Baseline

          -

          10. Forms

          -

          Complete and programmatically associated form labels and instructions

          -
          10.1 Test Procedure for Form Names
          - - - -

          Baseline Test ID: 10.1-FormName

          -
          Identify Content
          -
            -
          1. Find all form components. Examples include buttons, text fields, radio buttons, checkboxes, read-only fields, and multi-select lists.
          2. -
          3. Find all instructions and cues (textual and graphical) that are related to form components, including groupings, order of completion, special conditions or qualifiers, format instructions, etc.
          4. -
          -
          Test Instructions
          +

          10.1 Test Procedure for Form Names
          +
          + Baseline Test ID:
          10.1-FormName

          + + +

          Identify Content

          + +
            +
          1. Find all form components. Examples include buttons, text fields, radio buttons, checkboxes, read-only fields, and multi-select lists.
          2. +
          3. Find all instructions and cues (textual and graphical) that are related to form components, including groupings, order of completion, special conditions or qualifiers, format instructions, etc.
          4. +
          + + + +

          Test Instructions

          + + +
          1. Check that the combination of the accessible name and accessible description is not empty. [SC 4.1.2]
          2. Check that the non-empty combination of the accessible name and accessible description and other programmatic associations (e.g., table column and/or row associations) describes each form component and includes all relevant instructions and cues (textual and graphical). [SC 1.3.1] For details on the computation of the accessible name and accessible description, references include:
          - - -
          Test Results
          - - - -
            -
          • If any of the above checks fail, then SC 1.3.1, SC 4.1.2, and Baseline Requirement 10 fail.
          • -
          - + + + +

          Test Results

          + + + If any of the above checks fail, then Baseline Test 10.1-FormName fails. + + -

          Applicable WCAG/508 Requirement

          +

          Applicable WCAG/508 Requirement

          • WCAG2 1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.
          • @@ -151,7 +155,7 @@

            Expected Baseline Result

            - Fail + FAIL

            @@ -214,8 +218,8 @@

            Test Steps

            4 - If any of the above checks fail, then Baseline Test 10.1-FormName fails. - Test step 3 fails due to an empty accessible name and/or description in the text alternative computation output and therefore Baseline Test 10.1-FormName fails. + Determine whether any checks fail according to the 10.1 Test Procedure for Form Names test instructions. + This test fails due to an empty accessible name and/or description in the text alternative computation output and therefore Baseline Test 10.1-FormName fails. diff --git a/docs/testcases/TC10-008-dna.html b/docs/testcases/TC10-008-dna.html index 7197fb73..1c84487a 100644 --- a/docs/testcases/TC10-008-dna.html +++ b/docs/testcases/TC10-008-dna.html @@ -95,19 +95,24 @@

            Test Case Description


            Note: If the intent of the developer is to make the input element available to users as a part of meaningful ICT functionality, then the CSS property visibility:hidden should not be used with interactive elements.

            Applicable ICT Baseline

            -

            10. Forms

            -

            Complete and programmatically associated form labels and instructions

            -
            10.1 Test Procedure for Form Names
            - - - -

            Baseline Test ID: 10.1-FormName

            -
            Identify Content
            -
              -
            1. Find all form components. Examples include buttons, text fields, radio buttons, checkboxes, read-only fields, and multi-select lists.
            2. -
            3. Find all instructions and cues (textual and graphical) that are related to form components, including groupings, order of completion, special conditions or qualifiers, format instructions, etc.
            4. -
            -
            Test Instructions
            +

            10.1 Test Procedure for Form Names
            +
            + Baseline Test ID: 10.1-FormName

            + + +

            Identify Content

            + +
              +
            1. Find all form components. Examples include buttons, text fields, radio buttons, checkboxes, read-only fields, and multi-select lists.
            2. +
            3. Find all instructions and cues (textual and graphical) that are related to form components, including groupings, order of completion, special conditions or qualifiers, format instructions, etc.
            4. +
            + + + +

            Test Instructions

            + + +
            1. Check that the combination of the accessible name and accessible description is not empty. [SC 4.1.2]
            2. Check that the non-empty combination of the accessible name and accessible description and other programmatic associations (e.g., table column and/or row associations) describes each form component and includes all relevant instructions and cues (textual and graphical). [SC 1.3.1] For details on the computation of the accessible name and accessible description, references include: @@ -116,24 +121,22 @@
              Test Instructions
            3. HTML Accessibility API Mappings for input controls
            4. HTML Accessibility API Mappings for button element 
            5. HTML Accessibility API Mappings for input type="image"
            6. -
            7. HTML Accessibility API Mappings for Other Form Elements
            8. +
            9. HTML Accessibility API Mappings for Other Form Elements
          - - -
          Test Results
          - - - -
            -
          • If any of the above checks fail, then SC 1.3.1, SC 4.1.2, and Baseline Requirement 10 fail.
          • -
          • If there is no such content, then the result for the Baseline Test 10. Forms is DOES NOT APPLY (DNA)
          • -
          - + + + +

          Test Results

          + + + If any of the above checks fail, then Baseline Test 10.1-FormName fails. + + -

          Applicable WCAG/508 Requirement

          +

          Applicable WCAG/508 Requirement

          • WCAG2 1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.
          • @@ -204,10 +207,10 @@

            Test Steps

            - 1 - Find all form components. Examples include buttons, text fields, radio buttons, checkboxes, read-only fields, and multi-select lists. - The single input element in this test case is enclosed in the visibility:hidden CSS property which removes it from the accessibility tree, visible, and programmatic detection. Even though the code exists in the DOM, this property renders the element undetectable and therefore not applicable to this Baseline Test based on the results of test step 1. - + 1 + Determine whether this test applies according to the 10.1 Test Procedure for Form Names identify content instructions. + The single input element in this test case is enclosed in the visibility:hidden CSS property which removes it from the accessibility tree, visible, and programmatic detection. Even though the code exists in the DOM, this property renders the element undetectable and therefore not applicable to this Baseline Test. + diff --git a/docs/testcases/TC10-009-dna.html b/docs/testcases/TC10-009-dna.html index a9dbffe3..d7b1a81e 100644 --- a/docs/testcases/TC10-009-dna.html +++ b/docs/testcases/TC10-009-dna.html @@ -95,19 +95,24 @@

            Test Case Description


            Note: If the intent of the developer is to make the input element available to users as a part of meaningful ICT functionality, then the CSS property display:none should not be used with interactive elements.

            Applicable ICT Baseline

            -

            10. Forms

            -

            Complete and programmatically associated form labels and instructions

            -
            10.1 Test Procedure for Form Names
            - - - -

            Baseline Test ID: 10.1-FormName

            -
            Identify Content
            -
              -
            1. Find all form components. Examples include buttons, text fields, radio buttons, checkboxes, read-only fields, and multi-select lists.
            2. -
            3. Find all instructions and cues (textual and graphical) that are related to form components, including groupings, order of completion, special conditions or qualifiers, format instructions, etc.
            4. -
            -
            Test Instructions
            +

            10.1 Test Procedure for Form Names
            +
            + Baseline Test ID: 10.1-FormName

            + + +

            Identify Content

            + +
              +
            1. Find all form components. Examples include buttons, text fields, radio buttons, checkboxes, read-only fields, and multi-select lists.
            2. +
            3. Find all instructions and cues (textual and graphical) that are related to form components, including groupings, order of completion, special conditions or qualifiers, format instructions, etc.
            4. +
            + + + +

            Test Instructions

            + + +
            1. Check that the combination of the accessible name and accessible description is not empty. [SC 4.1.2]
            2. Check that the non-empty combination of the accessible name and accessible description and other programmatic associations (e.g., table column and/or row associations) describes each form component and includes all relevant instructions and cues (textual and graphical). [SC 1.3.1] For details on the computation of the accessible name and accessible description, references include: @@ -120,20 +125,18 @@
              Test Instructions
          - - -
          Test Results
          - - - -
            -
          • If any of the above checks fail, then SC 1.3.1, SC 4.1.2, and Baseline Requirement 10 fail.
          • -
          • If there is no such content, then the result for the Baseline Test 10. Forms is DOES NOT APPLY (DNA)
          • -
          - + + + +

          Test Results

          + + + If any of the above checks fail, then Baseline Test 10.1-FormName fails. + + -

          Applicable WCAG/508 Requirement

          +

          Applicable WCAG/508 Requirement

          • WCAG2 1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.
          • @@ -205,8 +208,8 @@

            Test Steps

            1 - Find all form components. Examples include buttons, text fields, radio buttons, checkboxes, read-only fields, and multi-select lists. - The single input element in this test case is enclosed in the display:none CSS property which removes it from the accessibility tree, visible, and programmatic detection. Even though the code exists in the DOM, this property renders the element undetectable and therefore not applicable to this Baseline Test based on the results of test step 1. + Determine whether this test applies according to the 10.1 Test Procedure for Form Names identify content instructions. + The single input element in this test case is enclosed in the display:none CSS property which removes it from the accessibility tree, visible, and programmatic detection. Even though the code exists in the DOM, this property renders the element undetectable and therefore not applicable to this Baseline Test.