diff --git a/explainer/index.html b/explainer/index.html index 5b815f07..1bf1b1b8 100644 --- a/explainer/index.html +++ b/explainer/index.html @@ -161,7 +161,7 @@

Structure of these guidelines

Some of these sections are in this document. You can find others in links within the sections.

- +
Core Structure

Figure 1 shows the core structure of WCAG 3.0. WCAG 3.0 has three levels of content with associated documentation. Guidelines form the top level. Each guideline contains multiple outcomes, with associated critical errors and outcomes scoring. Each outcome contains multiple methods, with an associated description and examples, tests, and test scoring.

@@ -199,7 +199,7 @@

Outcome rating

Methods structure

- +
Screenshot of a Method for Structured Content

Each outcome has one or more methods. There are three types of methods:

@@ -252,14 +252,14 @@

Additional Documentation and Scoring Information

The core structure has inter-relationships with supporting documents and the scoring process. Functional needs inform both outcomes and functional categories. The tests within methods are used to inform the scores for each outcome. Then outcome scores are aggregated to create scores by functional category and an overall score. These then result in a bronze rating. Silver and gold ratings build on the bronze rating to demonstrate improved accessibility. General information about guidelines is available in How To documents.

- +
Documentation and Scoring Structure

How tos

The How-To content provides explanatory material for each guideline that applies across technologies. This guidance explains how to apply the concepts presented in the guidelines for non-technical readers. This plain language resource includes information on getting started, who the guideline helps and how, as well information for project managers, designers and developers.  

- +
Example screenshot of a How-To for Structured Content

The example of a How-To for Structured Content provides basic information organized by tabs to help people get started with accessibility for structured content, plan for implementing accessible structured content across a project, design accessible structured content, and basics for developers new to accessibility of structured content. It also includes information on examples, the outcomes for meeting the guideline, and resources.

diff --git a/methods/audio-metadata/index.html b/methods/audio-metadata/index.html index 93910f14..e8351e08 100644 --- a/methods/audio-metadata/index.html +++ b/methods/audio-metadata/index.html @@ -10,11 +10,11 @@

Provides visual equivalent of speech and non-speech audio metadata

diff --git a/methods/caption-reflow/resources.html b/methods/caption-reflow/background.html similarity index 70% rename from methods/caption-reflow/resources.html rename to methods/caption-reflow/background.html index b8c2aca9..87806d15 100644 --- a/methods/caption-reflow/resources.html +++ b/methods/caption-reflow/background.html @@ -24,6 +24,18 @@

Non-W3C Resources

  • Enhancing Subtitles - BBC
    • +
    +

    Accessibility Support

    +

    to be written +

    +
    +
    +

    Assumptions

    + +
    + \ No newline at end of file diff --git a/methods/caption-reflow/description.html b/methods/caption-reflow/description.html index c363ffef..5f12eeae 100644 --- a/methods/caption-reflow/description.html +++ b/methods/caption-reflow/description.html @@ -9,28 +9,50 @@

    Description

    -

    Outcome and Functional Categories

    +

    Outcome

    This method supports the outcome Conveys information about the sound.

    Applies to immersive environments that support text equivalents (such as captions or transcripts) of audio track.

    -
    -

    Detailed description

    -
    -

    Maintaining reflow context in XR for Captions

    +
    +

    Platform

    +
      +
    • Media players
      • +
    • Immersive technology engines
      • +
    +
    +
    +

    Technology

    +
      +
    • Media
      • +
    • XR
      • +
    +
    +
    +

    Input aspects for testing

    +
      +
    • To be completed. [technical sources for input, such as DOM tree, Accessibility tree and CSS styling]
      • +
    +
    +
    +

    Summary

    +

    Users with vision impairments may need to resize or reflow captions, + subtitling or other text. It is important that caption, subtitling or text can reflow (in context) + within an XR environment without loss of information, context or functionality. +

    Content should not lose its context. This means that when captioning is related to speech they maintain their relationship with the source. If captioned text within the environment needs to be moved there is a persistent parent / child relationship between the related source and the related caption that enables either to be moved or other transformations to take place.

    See https://github.com/w3c/silver/issues/139 for example of traditional content in XR environment

    -
    -
    -

    Anti-Aliasing or use of vector graphics of Captions

    Depending on the environment - Captions should be resized without loss of quality. This may mean anti-aliasing options need to be available in XR or requiring the use of vector style graphics for captions and other text, which means they will resize more easily without loss of quality.

    -
    -

    Dependencies

    +
    +

    How it solves user need

    +

    People can choose a font format or size of their choice or use a mechanism with accessible affordances. This will allow them to resize and reflow text without either hiding or obscuring the content or substantial loss of context. The means of choice can be via (choose at least one):

      -

    • None.

      • +
    • user preference
      • +
    • personalization
      • +
    • other customisation setting
    - \ No newline at end of file + diff --git a/methods/caption-reflow/examples.html b/methods/caption-reflow/examples.html index 94c3a663..c7bb3d74 100644 --- a/methods/caption-reflow/examples.html +++ b/methods/caption-reflow/examples.html @@ -8,15 +8,29 @@

    Examples

    -
    -

    Example 1

    +
    +

    Passed

    +
    +

    Example 1

    A conversation is taking place between a group of people at a virtual meeting and a deaf user is tracking this discussion - there may be colour coding to distinguish the speakers and the caption colours may be related.

    The deaf user may later wish to explore the environment or look at some thing - and therefore move focus from the speakers but dock the captions, or keep them in some bespoke view. Therefore the speaker source and ‘their’ captions relationship can be maintained.

    This relationship maybe as simple as a text saying ‘Speaker name: Lorraine’, ‘Speaker name: Ruairi’ or similar. Or could be provided in markup. Providing the association of ‘source/caption’ in markup would allow greater movement, and further potential transformations.

    - -
    +
    +
    +
    +

    Failed

    +
    +

    To be written

    +
    +
    +
    +

    Inapplicable

    +
    +

    To be written

    +
    +
    \ No newline at end of file diff --git a/methods/caption-reflow/glossary.html b/methods/caption-reflow/glossary.html new file mode 100644 index 00000000..b152331b --- /dev/null +++ b/methods/caption-reflow/glossary.html @@ -0,0 +1,17 @@ + + + + Method - Glossary + + +
    +

    Glossary

    +
    +
    +
    +

    [term]

    +

    [definition] To be completed.

    +
    +
    + + \ No newline at end of file diff --git a/methods/caption-reflow/index.html b/methods/caption-reflow/index.html index 5934a7dc..e9c732d3 100644 --- a/methods/caption-reflow/index.html +++ b/methods/caption-reflow/index.html @@ -10,11 +10,12 @@

    Caption reflow

    diff --git a/methods/caption-reflow/intro.html b/methods/caption-reflow/intro.html index 103aac65..c9e59254 100644 --- a/methods/caption-reflow/intro.html +++ b/methods/caption-reflow/intro.html @@ -8,6 +8,11 @@

    Introduction

    +
    +

    Outcome and Functional Categories

    +

    This method supports the outcome Conveys information about the sound.

    +

    Applies to immersive environments that support text equivalents (such as captions or transcripts) of audio track.

    +

    Platform

    +
    +

    Input aspects for testing

    + +

    Summary

    Users with vision impairments may need to resize or reflow captions, subtitling or other text. It is important that caption, subtitling or text can reflow (in context) within an XR environment without loss of information, context or functionality.

    +

    Content should not lose its context. This means that when captioning is related to speech they maintain their relationship with the source. If captioned text within the environment needs to be moved there is a persistent parent / child relationship between the related source and the related caption that enables either to be moved or other transformations to take place.

    +

    See https://github.com/w3c/silver/issues/139 for example of traditional content in XR environment

    +

    Depending on the environment - Captions should be resized without loss of quality. This may mean anti-aliasing options need to be available in XR or requiring the use of vector style graphics for captions and other text, which means they will resize more easily without loss of quality.

    +

    How it solves user need

    diff --git a/methods/caption-reflow/tests.html b/methods/caption-reflow/tests.html index 8db7d897..7ca36456 100644 --- a/methods/caption-reflow/tests.html +++ b/methods/caption-reflow/tests.html @@ -8,8 +8,25 @@

    Tests

    -
    -

    Atomic Tests

    +
    +

    Get Started

    +

    To be written

    +
    +
    +

    Summary

    +

    To be written [overview of the test]

    +
    +
    +

    Applicability

    +

    To be written: This outcome applies to any [element names] element that is [condition] and for which one of the following is true: +

    +
    {excluded, ignored, exception}
    +
    [element] +
    +
    +
    +

    Expectations

    +

    To be written. [detail of the expectation] Tests from First Public Working Draft:

    • Check that there is support for captioning and subtitling of multimedia content.
    • Check that there is support for reflow of captions and other text.
      • @@ -17,13 +34,6 @@

      Atomic Tests

    • Check that there are semantics present that define context and relationships between related captions, subtitles and their source.
    • Check that where captions and other text may be placed on a second screen, context and source information is maintained.
    -
    -
    -

    Holistic Tests

    -
      -
    • Still to be developed. We will include this in a future working draft.
      • -
    -
    \ No newline at end of file diff --git a/methods/clear-words/index.html b/methods/clear-words/index.html index f24bb392..a0a6c96d 100644 --- a/methods/clear-words/index.html +++ b/methods/clear-words/index.html @@ -10,11 +10,11 @@

    Clear words

    diff --git a/methods/decorative-images/examples.html b/methods/decorative-images/examples.html index 705d19b8..99bf1844 100644 --- a/methods/decorative-images/examples.html +++ b/methods/decorative-images/examples.html @@ -8,60 +8,248 @@

    Examples

    - -
    -

    HTML decorative bitmaps

    -

    In HTML, decorative bitmap images need to have an alt attribute with no value (e.g. alt=”” or alt). For example:

    -
    -<img alt=”” src=”clipart-of-business-people-looking-at-a-computer-screen.jpg”>
-<img alt src=”clipart-of-someone-smiling-and-eating-a-salad.jpg”>
-
    -
    -
    -

    HTML decorative SVG

    -

    In HTML, decorative SVGs need to use the aria-hidden attribute with a value of “true”. For example:

    -
    -<button type=”button”>
-  <svg aria-hidden=”true” viewBox=”0 0 30 30”>
-    <use href=”#help-icon” />
-  </svg>
-  <span>Help</span>
-</button>
-
    -
    -
    -

    CSS

    -

    The CSS Generated Content Module Level 3 Working Draft includes support for alternative text for generated content. Alternative text with an empty value is specified as "". In the following example, if the pseudo-element is purely decorative and its function is covered elsewhere, setting alt to the empty string can avoid reading out the decorative element. Here the ARIA attribute will be spoken as collapsed. Without the empty string alt value, the content would also be spoken as Black right-pointing pointer.

    -
    -.expandable::before {
- content: "\25BA" / "";
-/* a.k.a. ► */
-}
-
    -
    -
    -

    ePub

    -

    If a decorative image is placed in an ePub document using HTML, it needs to have an alt attribute with no value and a role attribute with a value of presentation:

    -
    -<img alt="" role="presentation" src="images/decorative-edge.png" /> 
-
    -

    Adding the role attribute with a value of presentation will hide a decorative SVG in an ePub document:

    -
    -<svg lang="en" role="presentation" xml:lang="en" xmlns="http://www.w3.org/2000/svg">
-   …
-</svg>
-
    -
    -
    -

    PDF

    -

    Tagging PDFs for accessibility is covered in WCAG 2’s PDF4 Hiding decorative images with the Artifact tag in PDF documents.

    -
    + + +
    +

    Passed

    + +

    Passed example 1

    +

    This img element with an empty alt attribute which is not included in the accessibility tree is purely decorative.

    + +
    +
+<p>Happy new year!</p>
+<img src="/test-assets/shared/fireworks.jpg" alt="" />
+
+
    + +

    Passed example 2

    +
    
+<p>Happy new year!</p>
+<img src="/test-assets/shared/fireworks.jpg" aria-hidden="true" role="img" alt="" />
+
+
    + +

    Passed example 3

    +

    This img element that is ignored by assistive technologies because it has an explicit semantic role of none is purely decorative.

    +
    +
+<p>Happy new year!</p>
+<img src="/test-assets/shared/fireworks.jpg" role="none" alt="ignore me" />
+
+
    + +

    Passed example 4

    +

    This svg element that is ignored by assistive technologies because it has no attribute that would give it an accessible name is purely decorative.

    +
    +<p>Happy new year!</p>
+<svg height="200" xmlns="http://www.w3.org/2000/svg">
+  <polygon points="100,10 40,180 190,60 10,60 160,180" fill="yellow" />
+</svg>
+
+
    + +

    Passed example 5

    +

    This canvas element that is ignored by assistive technologies because it has no attribute that would give it an accessible name is purely decorative.

    +
    +
+<p>Happy new year!</p>
+<canvas id="newyear" width="200" height="200"></canvas>
+<script>
+  const ctx = document.querySelector('#newyear').getContext('2d')
+  ctx.fillStyle = 'yellow'
+  ctx.beginPath()
+  ctx.moveTo(100, 10)
+  ctx.lineTo(40, 180)
+  ctx.lineTo(190, 60)
+  ctx.lineTo(10, 60)
+  ctx.lineTo(160, 180)
+  ctx.fill()
+</script>
+
+
    +
    + +
    +

    Failed

    + +

    Failed example 1

    + +

    This img element with an empty ("") alt is not purely decorative.

    + +
    +
+<img src="/test-assets/shared/w3c-logo.png" alt="" />
+
+
    + +

    Failed example 2

    + +

    This img element which is not included in the accessibility tree because it has an explicit semantic role of none is not purely decorative.

    + +
    +
+<img src="/test-assets/shared/w3c-logo.png" aria-hidden="true" alt="W3C logo" />
+
+
    + +

    Failed example 3

    +

    This img element which is not included in the accessibility tree because it has an explicit semantic role of none is not purely decorative.

    + +
    +
+<img src="/test-assets/shared/w3c-logo.png" role="none" alt="W3C logo" />
+
+
    + +

    Failed example 4

    +

    This svg element which has a semantic role of graphics-document and an empty ("") accessible name is not purely decorative.

    + +
    +<p>Best W3C logo:</p>
+<svg viewBox="0 0 512 512">
+  <path d="M108.4 0h23v22.8h21.2V0h23v69h-23V46h-21v23h-23.2M206 23h-20.3V0h63.7v23H229v46h-23M259.5 0h24.1l14.8 24.3L313.2 0h24.1v69h-23V34.8l-16.1 24.8l-16.1-24.8v34.2h-22.6M348.7 0h23v46.2h32.6V69h-55.6"/>
+  <path fill="#e44d26" d="M107.6 471l-33-370.4h362.8l-33 370.2L255.7 512" />
+  <path fill="#f16529" d="M256 480.5V131H404.3L376 447" />
+  <path fill="#ebebeb" d="M142 176.3h114v45.4h-64.2l4.2 46.5h60v45.3H154.4M156.4 336.3H202l3.2 36.3 50.8 13.6v47.4l-93.2-26" />
+  <path fill="#fff" d="M369.6 176.3H255.8v45.4h109.6M361.3 268.2H255.8v45.4h56l-5.3 59-50.7 13.6v47.2l93-25.8" />
+</svg>
+
+
    + +

    Failed example 5

    +

    This canvas element which has no semantic role and an empty ("") accessible name is not purely decorative.

    +
    +
+<canvas id="w3c" width="200" height="60"></canvas>
+<script>
+  const ctx = document.querySelector('#w3c').getContext('2d')
+  ctx.font = '30px Arial'
+  ctx.fillText"('WCAG Rules!', 20, 40)
+</script>
+
+
    +
    + +
    + +

    Inapplicable

    + +

    Inapplicable example 1

    + +

    This img element is included in the accessibility tree because the alt attribute is not empty ("").

    +
    +
+  <img src="/test-assets/shared/w3c-logo.png" alt>="W3C" />
+
+
    + +

    Inapplicable example 2

    + +

    This img element is neither visible nor included in the accessibility tree.

    + +
    +<img src="/test-assets/shared/w3c-logo.png" style="display:none" alt="" />
+
+
    + +

    Inapplicable example 3

    + +

    This img element is not visible because it is positioned off screen.

    + +
    +
+<style>
+  img {
+    position: absolute;
+    top: -9999em;
+  }
+</style>
+<img src="/test-assets/shared/fireworks.jpg" alt="" />
+
+
    + +

    Inapplicable example 4

    +

    This svg element is ignored because it is a child of a link that provides its accessible name.

    + +
    +
+<a href="https://example.org" aria-label="SVG star">
+  <svg height="200" xmlns="http://www.w3.org/2000/svg">
+    <polygon points="100,10 40,180 190,60 10,60 160,180" fill="yellow" />
+  </svg>
+</a>
+
+
    + +

    Inapplicable example 5

    +

    This svg element has a semantic role of img and an accessible name from its aria-label attribute.

    + +
    +
+<svg viewBox="0 0 512 512" role="img" aria-label="HTML 5 logo">
+  <path d="M108.4 0h23v22.8h21.2V0h23v69h-23V46h-21v23h-23.2M206 23h-20.3V0h63.7v23H229v46h-23M259.5 0h24.1l14.8 24.3L313.2 0h24.1v69h-23V34.8l-16.1 24.8l-16.1-24.8v34.2h-22.6M348.7 0h23v46.2h32.6V69h-55.6" />
+  <path fill="#e44d26" d="M107.6 471l-33-370.4h362.8l-33 370.2L255.7 512" />
+  <path fill="#f16529" d="M256 480.5V131H404.3L376 447" />
+  <path fill="#ebebeb" d="M142 176.3h114v45.4h-64.2l4.2 46.5h60v45.3H154.4M156.4 336.3H202l3.2 36.3 50.8 13.6v47.4l-93.2-26" />
+  <path fill="#fff" d="M369.6 176.3H255.8v45.4h109.6M361.3 268.2H255.8v45.4h56l-5.3 59-50.7 13.6v47.2l93-25.8" />
+</svg>
+
+
    + +

    Inapplicable example 6

    +

    This canvas element is not visible because it is completely transparent.

    + +
    <canvas width="200" height="200"></canvas>
    + +

    Inapplicable example 7

    +

    This canvas element has a semantic role of img and an accessible name from its aria-label attribute.

    + +
    +
+<canvas id="w3c" width="200" height="60" role="img" aria-label="WCAG Rules!"></canvas>
+<script>
+  const ctx = document.querySelector('#w3c').getContext('2d')
+  ctx.font = '30px Arial'
+  ctx.fillText('WCAG Rules!', 20, 40)
+</script>
+
+
    + +

    Inapplicable example 8

    +

    This img element is visible but included in the accessibility tree.

    + +

    Note: While it might be better for the PDF icon to be ignored by assistive technologies, because assistive technologies will announce “PDF” twice, the image is not purely decorative. Having assistive technologies ignore it is not required by Success Criterion 1.1.1 Non-text content.

    + +
    +
+<img src="/test-assets/shared/pdf-icon.png" alt="PDF" /> PDF document
+
+
    + +

    Inapplicable example 9

    +

    This is a div element with a background image. Background images must be tested separate from this rule.

    + +
    <p>Happy new year!</p>
+<div
+  style="
+  width: 260px;
+  height: 260px;
+  background:url(/test-assets/shared/fireworks.jpg) no-repeat;"
+></div>
+
+
    + +

    Inapplicable example 10

    +

    This img element has an src attribute which will cause the image request state to be Broken.

    + +
    +
+<img src="/test-assets/does-not-exist.png" alt="" />
+
+
    + +
    \ No newline at end of file diff --git a/methods/decorative-images/glossary.html b/methods/decorative-images/glossary.html new file mode 100644 index 00000000..32cf5ec0 --- /dev/null +++ b/methods/decorative-images/glossary.html @@ -0,0 +1,208 @@ + + + + Method - Glossary + + +
    +

    Glossary

    +
    +
    +
    +

    Accessible Name

    +

    The accessible name is the programmatically determined name of a user interface element that is included in the accessibility tree.

    +

    The accessible name is calculated using the accessible name and description computation.

    +

    For native markup languages, such as HTML and SVG, additional information on how to calculate the accessible name can be found in HTML Accessibility API Mappings 1.0, Accessible Name and Description Computation (working draft) and SVG Accessibility API Mappings, Name and Description (working draft).

    +

    For more details, see ACT’s examples of accessible name.

    +
    +

    Note: As per the accessible name and description computation, each element always has an accessible name. When no accessible name is provided, the element will nonetheless be assigned an empty ("") one.

    +
    +
    +

    Note: As per the accessible name and description computation, accessible names are flat string trimmed of leading and trailing whitespace. Notably, it is not possible for a non-empty accessible name to be composed only of whitespace since these must be trimmed.

    +
    +
    + +
    +

    Accessibility Support For Accessible Name

    + +
    + +
    +

    Accessibility Support For Definition Of Semantic Role For Semantic Role

    + + +
    + +
    +

    Accessibility Support For Explicit Semantic Role

    +

    Some browsers and assistive technologies treat the tokens of the role attribute as case-sensitive. Unless lowercase letters are used for the value of the role attribute, not all user agents will be able to interpret the tokens correctly. ARIA in HTML (working draft) also specifies that authors must use lowercase letters for the role and aria-* attributes.

    +
    + +
    +

    Accessibility Support For Implicit Semantic Role

    +

    Images with an empty alt attribute should have an implicit role of presentation, according to the HTML Accessibility API Mapping (work in progress). However, there are several popular browsers that do not treat images with empty alt attribute as having a role of presentation. Instead, they add the img element to the accessibility tree with a role of either img or graphic.

    +
    + +
    +

    Ancestor

    +

    An object A is called an ancestor of an object B if and only if B is a descendant of A.

    +
    + +
    +

    Current Request

    +

    An img element has a current request and a pending request. The current request is initially set to a new image request. The pending request is initially set to null.

    +
    + +
    +

    Explicit Semantic Role

    +

    The explicit semantic role of an element is determined by its role attribute (if any).

    +

    The role attribute takes a list of tokens. The explicit semantic role is the first valid role in this list. The valid roles are all non-abstract roles from WAI-ARIA Specifications. If the element has no role attribute, or if it has one with no valid role, then this element has no explicit semantic role.

    +

    Other roles may be added as they become available. Not all roles will be supported in all assistive technologies. Testers are encouraged to adjust which roles are allowed according to the accessibility support base line. For the purposes of executing test cases in all rules, it should be assumed that all roles are supported by assistive technologies so that none of the roles fail due to lack of accessibility support.

    +
    + +
    +

    Flat Tree

    +

    While Selectors operates on the DOM tree as the host language presents it, with separate trees that are unreachable via the standard parent/child relationship, the rest of CSS needs a single unified tree structure to work with. This is called the flattened element tree (or flat tree)

    +
    + +
    +

    Focusable

    +

    Elements that can become the target of keyboard input as described in the HTML specification of focusable and HTML specification of can be focused.

    +
    + +
    +

    Hidden State

    +

    An HTML element’s hidden state is “true” if at least one of the following is true for itself or any of its ancestors in the flat tree:

    + +

    In any other case, the element’s hidden state is “false”.

    +
    + +
    +

    Image Request State

    + +

    An image request has a state, current URL, and image data. An image request's state is one of the following:

    + +
    +
    Unavailable
    +
    The user agent hasn't obtained any image data, or has obtained some or all of the image data but hasn't yet decoded enough of the image to get the image dimensions.
    +
    Partially available
    +
    The user agent has obtained some of the image data and at least the image dimensions are available.
    +
    Completely available
    +
    The user agent has obtained all of the image data and at least the image dimensions are available.
    +
    Broken
    +
    The user agent has obtained all of the image data that it can, but it cannot even decode the image enough to get the image dimensions (e.g. the image is corrupted, or the format is not supported, or no data could be obtained).
    +
    + +
    + +
    +

    Implicit Semantic Role

    +

    The implicit semantic role of an element is a pre-defined value given by the host language which depends on the element and its ancestors.

    +

    Implicit roles for HTML and SVG, are documented in the HTML accessibility API mappings (working draft) and the SVG accessibility API mappings (working draft).

    +
    + +
    +

    Included In The Accessibility Tree

    +

    Elements included in the accessibility tree of platform specific accessibility APIs. Elements in the accessibility tree are exposed to assistive technologies, allowing users to interact with the elements in a way that meet the requirements of the individual user.

    +

    The general rules for when elements are included in the accessibility tree are defined in the core accessibility API mappings. For native markup languages, such as HTML and SVG, additional rules for when elements are included in the accessibility tree can be found in the HTML accessibility API mappings (working draft) and the SVG accessibility API mappings (working draft).

    +

    For more details, see ACT’s examples of included in the accessibility tree.

    +
    +

    Note: Users of assistive technologies might still be able to interact with elements that are not included in the accessibility tree. An example of this is a focusable element with an aria-hidden attribute with a value of true. Such an element could still be interacted using sequential keyboard navigation regardless of the assistive technologies used, even though the element would not be included in the accessibility tree.

    +
    + +
    + +
    +

    Marked As Decorative

    +

    An element is marked as decorative if one of the following conditions is true:

    + +

    Elements are marked as decorative as a way to convey the intention of the author that they are pure decoration. It is different from the element actually being pure decoration as authors may make mistakes. It is different from the element being effectively ignored by assistive technologies as rules such as presentational roles conflict resolution may overwrite this intention.

    +

    Elements can also be ignored by assistive technologies if their hidden state is true. This is different from marking the element as decorative and does not convey the same intention. Notably, the hidden state of an element may change as users interact with the page (showing and hiding elements) while being marked as decorative should stay the same through all states of the page.

    +
    + +
    +

    Roles Supporting Name from Author

    +

    All roles support name from author with two exceptions. The roles that do not support name from author are presentation and none.

    +
    + +
    +

    Outcome

    +

    An outcome is a conclusion that comes from evaluating an ACT Rule on a test subject or one of its constituent test target. An outcome can be one of the three following types:

    +
    +
    Inapplicable:
    +
    No part of the test subject matches the applicability.
    +
    Passed:
    +
    A test target meets all expectations.
    +
    Failed:
    +
    A test target does not meet all expectations
    +
    +
    +

    Note: A rule has one passed or failed outcome for every test target. When there are no test targets the rule has one inapplicable outcome. This means that each test subject will have one or more outcomes.

    +
    +
    +

    Note: Implementations using the EARL 1.0 Schema can express the outcome with the outcome property. In addition to passed, failed and inapplicable, EARL 1.0 also defined an incomplete outcome. While this cannot be the outcome of an ACT Rule when applied in its entirety, it often happens that rules are only partially evaluated. For example, when applicability was automated, but the expectations have to be evaluated manually. Such “interim” results can be expressed with the incomplete outcome.

    +
    + +
    + +
    +

    Pure Decoration

    +

    serving only an aesthetic purpose, providing no information, and having no functionality.

    +
    +

    Note: Text is only purely decorative if the words can be rearranged or substituted without changing their purpose.

    +
    +
    + +
    +

    Semantic Role

    +

    The semantic role of an element is determined by the first of these cases that applies:

    +
    +
    Conflict:
    +
    If the element is marked as decorative, but the element is included in the accessibility tree; or would be included in the accessibility tree when its hidden state is false, then its semantic role is its implicit role.
    +
    Explicit:
    +
    If the element has an explicit role, then its semantic role is its explicit role.
    +
    Implicit:
    +
    The semantic role of the element is its implicit role.
    +
    +
    + +
    +

    Visible

    +

    Content perceivable through sight.

    +

    Content is considered visible if making it fully transparent would result in a difference in the pixels rendered for any part of the document that is currently within the viewport or can be brought into the viewport via scrolling.

    +

    Content is defined in WCAG.

    +

    For more details, see ACT examples of visible.

    +
    + +
    +

    WAI-ARIA Specifications

    +

    The WAI-ARIA Specifications group both the WAI ARIA W3C Recommendation and ARIA modules, namely:

    + + +
    +

    Note: depending on the type of content being evaluated, part of the specifications might be irrelevant and should be ignored.

    +
    +
    +
    + + \ No newline at end of file diff --git a/methods/decorative-images/index.html b/methods/decorative-images/index.html index 04301922..f5832fe4 100644 --- a/methods/decorative-images/index.html +++ b/methods/decorative-images/index.html @@ -10,11 +10,11 @@

    Decorative images