From ec71e9c16c6154ebbc3c7f5b32f5d70a0c7ef2bc Mon Sep 17 00:00:00 2001 From: Jon Date: Sun, 21 Jul 2019 12:32:50 -0500 Subject: [PATCH 01/24] initial proposal for accessible name from heading --- common/script/aria.js | 52 +++++++++++++++++---------- index.html | 84 ++++++++++++++++++++++++++++--------------- 2 files changed, 88 insertions(+), 48 deletions(-) diff --git a/common/script/aria.js b/common/script/aria.js index b0d6cf3a2..69d25aa8f 100644 --- a/common/script/aria.js +++ b/common/script/aria.js @@ -125,7 +125,7 @@ require(["core/pubsubhub"], function( respecEvents ) { }) ; } - + } ; var s = "var roleInfo = " + JSON.stringify(roleInfo, null, '\t') ; @@ -173,11 +173,11 @@ require(["core/pubsubhub"], function( respecEvents ) { var abstract = container.querySelector("." + type + "-applicability"); if ((abstract.textContent || abstract.innerText) === "All elements of the base markup") { globalSP.push({ is: type, title: title, name: content, desc: desc, prohibited: false }); - } + } else if ((abstract.textContent || abstract.innerText) === "All elements of the base markup except for some roles or elements that prohibit its use") { globalSP.push({ is: type, title: title, name: content, desc: desc, prohibited: true }); - } - + } + // the rdef is gone. if we are in a div, convert that div to a section if (container.nodeName.toLowerCase() == "div") { @@ -192,7 +192,7 @@ require(["core/pubsubhub"], function( respecEvents ) { container.parentNode.replaceChild(sec, container) ; } }); - + if (!skipIndex) { // we have all the properties and states - spit out the // index @@ -267,6 +267,7 @@ require(["core/pubsubhub"], function( respecEvents ) { var fromContent = ""; var fromEncapsulation = ""; var fromLegend = ""; + var fromHeading = ""; var fromProhibited = ""; $.each(document.querySelectorAll("rdef"), function(i,item) { @@ -317,7 +318,7 @@ require(["core/pubsubhub"], function( respecEvents ) { parentRoles.push(s); }); } - // are there supported states / properties in this role? + // are there supported states / properties in this role? var attrs = []; $.each(container.querySelectorAll(".role-properties, .role-required-properties, .role-disallowed"), function(i, node) { if (node && ((node.textContent && node.textContent.length !== 1) || (node.innerText && node.innerText.length !== 1))) { @@ -330,8 +331,8 @@ require(["core/pubsubhub"], function( respecEvents ) { var type = (item.localName === "pref" ? "property" : "state"); var req = $(node).hasClass("role-required-properties"); var dis = $(node).hasClass("role-disallowed"); - attrs.push( { is: type, name: name, required: req, disallowed: dis } ); - + attrs.push( { is: type, name: name, required: req, disallowed: dis } ); + // remember that the state or property is // referenced by this role propList[name].roles.push(title); @@ -351,7 +352,7 @@ require(["core/pubsubhub"], function( respecEvents ) { if (node.textContent.indexOf("author") !== -1) { fromAuthor += "
  • " + content + "" + req + "
    • "; - } + } if (!isAbstract && node.textContent.indexOf("content") !== -1) { fromContent += "
  • " + content + "" + "
    • "; } @@ -359,11 +360,14 @@ require(["core/pubsubhub"], function( respecEvents ) { fromProhibited += "
  • " + content + "" + req + "
    • "; } if (node.textContent.indexOf("encapsulation") !== -1) { - fromEncapsulation += "
  • " + content + "" + req + "
    • "; + fromEncapsulation += "
  • " + content + "" + req + "
    • "; } if (node.textContent.indexOf("legend") !== -1) { fromLegend += "
  • " + content + "" + req + "
    • "; - } + } + if (node.textContent.indexOf("heading") !== -1) { + fromHeading += "
  • " + content + "" + req + "
    • "; + } }); } if (container.nodeName.toLowerCase() == "div") { @@ -396,7 +400,7 @@ require(["core/pubsubhub"], function( respecEvents ) { return myList; } }; - + if (!skipIndex) { // build up the complete inherited SP lists for each role // however, if the role already specifies an item, do not include it @@ -445,7 +449,7 @@ require(["core/pubsubhub"], function( respecEvents ) { } } }); - + // Update state and property role references var getAllSubRoles = function(role) { var ref = subRoles[role]; @@ -464,7 +468,7 @@ require(["core/pubsubhub"], function( respecEvents ) { return []; } }; - + $.each(propList, function(i, item) { var output = ""; var section = document.querySelector("#" + item.name); @@ -511,7 +515,7 @@ require(["core/pubsubhub"], function( respecEvents ) { } } }); - + // spit out the index var node = document.getElementById("index_role"); var parentNode = node.parentNode; @@ -562,6 +566,16 @@ require(["core/pubsubhub"], function( respecEvents ) { parentNode.replaceChild(list, node); } + node = document.getElementById("index_fromheading"); + if (node) { + parentNode = node.parentNode; + list = document.createElement("ul"); + list.id = "index_fromheading"; + list.className = "compact"; + list.innerHTML = fromHeading; + parentNode.replaceChild(list, node); + } + node = document.getElementById("index_fromprohibited"); if (node) { parentNode = node.parentNode; @@ -593,15 +607,15 @@ require(["core/pubsubhub"], function( respecEvents ) { } // prune out unused rows throughout the document - + $.each(document.querySelectorAll(".role-abstract, .role-parent, .role-base, .role-related, .role-scope, .role-mustcontain, .role-required-properties, .role-properties, .role-namefrom, .role-namerequired, .role-namerequired-inherited, .role-childpresentational, .role-presentational-inherited, .state-related, .property-related,.role-inherited, .role-children, .property-descendants, .state-descendants, .implicit-values"), function(i, item) { var content = $(item).text(); if (content.length === 1 || content.length === 0) { // there is no item - remove the row item.parentNode.remove(); - } else if (content === "Placeholder" - && !skipIndex - && (item.className === "role-inherited" + } else if (content === "Placeholder" + && !skipIndex + && (item.className === "role-inherited" || item.className === "role-children" || item.className === "property-descendants" || item.className === "state-descendants" )) { diff --git a/index.html b/index.html index 41dd752b5..e5f62a174 100644 --- a/index.html +++ b/index.html @@ -494,7 +494,7 @@

    Inherited States and Properties

    Prohibited States and Properties

    List of states and properties that are prohibited on a role. Authors MUST NOT specify a prohibited state or property.

    A host language attribute with the appropriate implicit WAI-ARIA semantic would also prohibit a state or property in this section.

    - +

    Required Owned Elements

    @@ -534,6 +534,7 @@

    Accessible Name Calculation

  • contents: name comes from the text value of the element node. Although this may be allowed in addition to "author" in some roles, this is used in content only if higher priority "author" features are not provided. Priority is defined by the accessible name and description computation algorithm. [[ACCNAME-1.1]]
  • encapsulation: name comes from the text value of the element node with role label that is the closest ancestor. Although "encapsulation" may be allowed in addition to "author" and "contents" in some roles, "encapsulation" is used only if higher priority "author" features are not provided. Priority is defined by the accessible name and description computation algorithm. [[ACCNAME-1.1]]
  • legend: name comes from the text value of the first descendant element node with the role of legend. Although "legend" may be allowed in addition to "author" in some roles, "legend" is used in content only if higher priority "author" features are not provided. Priority is defined by the accessible name and description computation algorithm. [[ACCNAME-1.1]]
    • +
  • heading: name comes from the text value of the first descendant element node with the role of heading. Although "heading" may be allowed in addition to "author" in some roles, "heading" is used in content only if higher priority "author" features are not provided. Priority is defined by the accessible name and description computation algorithm. [[ACCNAME-1.1]]
  • prohibited: the element has no name. Authors MUST NOT use the aria-label or aria-labelledby attributes to name the element.
    • @@ -568,7 +569,12 @@

    Roles Supporting Name from Encapsulation

    Roles Supporting Name from Legend

    -
    + +
    +

    Roles Supporting Name from Heading

    +
    +
    +

    Roles which cannot be named (Name prohibited)

    @@ -1090,7 +1096,12 @@

    Definition of Roles

    Name From: - author + +
      +
    • heading
      • +
    • author
      • +
    + Accessible Name Required: @@ -1517,7 +1528,7 @@

    Definition of Roles

    Inherited States and Properties: Placeholder - + Name From: author @@ -1696,9 +1707,9 @@

    Definition of Roles

    • aria-label
    • aria-labelledby
      • -
    + - + Name From: prohibited @@ -1982,9 +1993,9 @@

    Definition of Roles

    • aria-label
    • aria-labelledby
      • -
    + - + Name From: prohibited @@ -2366,7 +2377,12 @@

    Definition of Roles

    Name From: - author + +
      +
    • heading
      • +
    • author
      • +
    + Accessible Name Required: @@ -2671,9 +2687,9 @@

    Definition of Roles

    • aria-label
    • aria-labelledby
      • -
    + - + Name From: prohibited @@ -2997,9 +3013,9 @@

    Definition of Roles

    • aria-label
    • aria-labelledby
      • -
    + - + Name From: prohibited @@ -3848,7 +3864,7 @@

    Definition of Roles

    Supported States and Properties: - + Inherited States and Properties: Placeholder @@ -3859,9 +3875,9 @@

    Definition of Roles

    • aria-label
    • aria-labelledby
      • -
    + - + Name From: prohibited @@ -4691,7 +4707,12 @@

    Definition of Roles

    Name From: - author + +
      +
    • heading
      • +
    • author
      • +
    + Accessible Name Required: @@ -5562,7 +5583,12 @@

    Plain HTML or Polyfill DOM Result of the MathML Quadratic Formula

    Name From: - author + +
      +
    • heading
      • +
    • author
      • +
    + Accessible Name Required: @@ -5932,9 +5958,9 @@
    Note regarding the ARIA 1.1 none role.
    • aria-label
    • aria-labelledby
      • -
    + - + Name From: prohibited @@ -6092,9 +6118,9 @@
    Presentational Roles Conflict Resolution
    • aria-label
    • aria-labelledby
      • -
    + - + Name From: prohibited @@ -7895,9 +7921,9 @@
    Presentational Roles Conflict Resolution
    • aria-label
    • aria-labelledby
      • -
    + - + Name From: prohibited @@ -8057,9 +8083,9 @@
    Presentational Roles Conflict Resolution
    • aria-label
    • aria-labelledby
      • -
    + - + Name From: prohibited @@ -8144,9 +8170,9 @@
    Presentational Roles Conflict Resolution
    • aria-label
    • aria-labelledby
      • -
    + - + Name From: prohibited @@ -12777,7 +12803,7 @@

    States and Properties

  • Otherwise, ignore the value and treat the property as not present.
    • - +

    In UIA, the user agent might leave the corresponding property set to "unsupported."

    User agents MUST NOT expose WAI-ARIA attributes that reference unresolved IDs. For example:

      From f73203ec0a1c1254a8c7cd49d7e9c98cd4e60a82 Mon Sep 17 00:00:00 2001 From: Jon Date: Sun, 21 Jul 2019 14:29:37 -0500 Subject: [PATCH 02/24] added dialog and alertdialog --- index.html | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/index.html b/index.html index e5f62a174..684223d8f 100644 --- a/index.html +++ b/index.html @@ -920,7 +920,12 @@

      Definition of Roles

      Name From: - author + +
        +
      • heading
        • +
      • author
        • +
      + Accessible Name Required: @@ -2773,7 +2778,12 @@

      Definition of Roles

      Name From: - author + +
        +
      • heading
        • +
      • author
        • +
      + Accessible Name Required: From 8547f5e5183ff2ab2fc7677a43bf7dd1e694ca47 Mon Sep 17 00:00:00 2001 From: Jon Date: Wed, 31 Jul 2019 16:59:27 -0500 Subject: [PATCH 03/24] added nesting restrictions for naming and added region as a potential role for naming with header --- index.html | 23 ++++++++++++++--------- 1 file changed, 14 insertions(+), 9 deletions(-) diff --git a/index.html b/index.html index 9b0aa7163..4c846ff50 100644 --- a/index.html +++ b/index.html @@ -533,8 +533,8 @@

      Accessible Name Calculation

    • author: name comes from values provided by the author in explicit markup features such as the aria-label attribute, the aria-labelledby attribute, or the host language labeling mechanism, such as the alt or title attributes in HTML, with HTML title attribute having the lowest precedence for specifying a text alternative.
    • contents: name comes from the text value of the element node. Although this may be allowed in addition to "author" in some roles, this is used in content only if higher priority "author" features are not provided. Priority is defined by the accessible name and description computation algorithm. [[ACCNAME-1.1]]
    • encapsulation: name comes from the text value of the element node with role label that is the closest ancestor. Although "encapsulation" may be allowed in addition to "author" and "contents" in some roles, "encapsulation" is used only if higher priority "author" features are not provided. Priority is defined by the accessible name and description computation algorithm. [[ACCNAME-1.1]]
      • +
    • heading: name comes from the text value of the first descendant element node with the role of heading. The heading can only name the closest ancestor element that allows name from heading. Although "heading" may be allowed in addition to "author" in some roles, "heading" is used in content only if higher priority "author" features are not provided. Priority is defined by the accessible name and description computation algorithm. [[ACCNAME-1.1]]
    • legend: name comes from the text value of the first descendant element node with the role of legend. Although "legend" may be allowed in addition to "author" in some roles, "legend" is used in content only if higher priority "author" features are not provided. Priority is defined by the accessible name and description computation algorithm. [[ACCNAME-1.1]]
      • -
    • heading: name comes from the text value of the first descendant element node with the role of heading. Although "heading" may be allowed in addition to "author" in some roles, "heading" is used in content only if higher priority "author" features are not provided. Priority is defined by the accessible name and description computation algorithm. [[ACCNAME-1.1]]
    • prohibited: the element has no name. Authors MUST NOT use the aria-label or aria-labelledby attributes to name the element.
      • @@ -565,14 +565,14 @@

      Roles Supporting Name from Encapsulation

    -
    -

    Roles Supporting Name from Legend

    -
    -
    -

    Roles Supporting Name from Heading

    +
    +
    +
    +

    Roles Supporting Name from Legend

    +
    @@ -3355,9 +3355,9 @@

    Definition of Roles

    + - + Name From: prohibited @@ -6641,7 +6641,12 @@
    Presentational Roles Conflict Resolution
    Name From: - author + + + Accessible Name Required: From 5cc0b8433226af84800f24f438e3bd1bdc0ecb7a Mon Sep 17 00:00:00 2001 From: Jon Date: Thu, 1 Aug 2019 10:18:15 -0500 Subject: [PATCH 04/24] updated defintion of region role authoring practices --- index.html | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/index.html b/index.html index 4c846ff50..fa93d54d3 100644 --- a/index.html +++ b/index.html @@ -6585,7 +6585,8 @@
    Presentational Roles Conflict Resolution

    A perceivable section containing content that is relevant to a specific, author-specified purpose and sufficiently important that users will likely want to be able to navigate to the section easily and to have it listed in a summary of the page. Such a page summary could be generated dynamically by a user agent or assistive technology.

    Authors SHOULD limit use of the region role to sections containing content with a purpose that is not accurately described by one of the other landmark roles, such as main, complementary, or navigation.

    -

    Authors MUST give each element with role region a brief label that describes the purpose of the content in the region. Authors SHOULD reference a visible label with aria-labelledby if a visible label is present. Authors SHOULD include the label inside of a heading whenever possible. The heading MAY be an instance of the standard host language heading element or an instance of an element with role heading.

    +

    Authors MUST give each element with role region a brief label that describes the purpose of the content in the region. Authors SHOULD use a visible heading to provide a label whenever possible. The heading MAY be an instance of the standard host language heading element or an instance of an element with role heading. For host languages that support elments with the default role of region (e.g. HTML section), an explict role=region attribute must be defined to enable the heading labeling technique.

    +

    If a heading is not used authors SHOULD reference a visible label with aria-labelledby if a visible label is present.

    Assistive technologies SHOULD enable users to quickly navigate to elements with role region. Mainstream user agents MAY enable users to quickly navigate to elements with role region.

    From ddf5ee3d5acadd2e3f80dcebc4edafb917226533 Mon Sep 17 00:00:00 2001 From: Jon Date: Thu, 1 Aug 2019 10:20:07 -0500 Subject: [PATCH 05/24] updated defintion of region role authoring practices --- index.html | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/index.html b/index.html index fa93d54d3..607d5ae7e 100644 --- a/index.html +++ b/index.html @@ -6585,8 +6585,7 @@
    Presentational Roles Conflict Resolution

    A perceivable section containing content that is relevant to a specific, author-specified purpose and sufficiently important that users will likely want to be able to navigate to the section easily and to have it listed in a summary of the page. Such a page summary could be generated dynamically by a user agent or assistive technology.

    Authors SHOULD limit use of the region role to sections containing content with a purpose that is not accurately described by one of the other landmark roles, such as main, complementary, or navigation.

    -

    Authors MUST give each element with role region a brief label that describes the purpose of the content in the region. Authors SHOULD use a visible heading to provide a label whenever possible. The heading MAY be an instance of the standard host language heading element or an instance of an element with role heading. For host languages that support elments with the default role of region (e.g. HTML section), an explict role=region attribute must be defined to enable the heading labeling technique.

    -

    If a heading is not used authors SHOULD reference a visible label with aria-labelledby if a visible label is present.

    +

    Authors MUST give each element with role region a brief label that describes the purpose of the content in the region. Authors SHOULD use a visible heading to provide a label whenever possible. The heading MAY be an instance of the standard host language heading element or an instance of an element with role heading. For host languages that support elments with the default role of region (e.g. HTML section), an explict role=region attribute must be defined to enable the heading labeling technique. If a heading is not used authors SHOULD reference a visible label with aria-labelledby if a visible label is present.

    Assistive technologies SHOULD enable users to quickly navigate to elements with role region. Mainstream user agents MAY enable users to quickly navigate to elements with role region.

    From dfe9ff97bab0d2c4229d9e0676e0402f675f59d0 Mon Sep 17 00:00:00 2001 From: Jon Date: Thu, 1 Aug 2019 10:59:22 -0500 Subject: [PATCH 06/24] updated defintion of region role authoring practices --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index 607d5ae7e..cec891429 100644 --- a/index.html +++ b/index.html @@ -6585,7 +6585,7 @@
    Presentational Roles Conflict Resolution

    A perceivable section containing content that is relevant to a specific, author-specified purpose and sufficiently important that users will likely want to be able to navigate to the section easily and to have it listed in a summary of the page. Such a page summary could be generated dynamically by a user agent or assistive technology.

    Authors SHOULD limit use of the region role to sections containing content with a purpose that is not accurately described by one of the other landmark roles, such as main, complementary, or navigation.

    -

    Authors MUST give each element with role region a brief label that describes the purpose of the content in the region. Authors SHOULD use a visible heading to provide a label whenever possible. The heading MAY be an instance of the standard host language heading element or an instance of an element with role heading. For host languages that support elments with the default role of region (e.g. HTML section), an explict role=region attribute must be defined to enable the heading labeling technique. If a heading is not used authors SHOULD reference a visible label with aria-labelledby if a visible label is present.

    +

    Authors MUST give each element with role region a brief label that describes the purpose of the content in the region. Authors SHOULD use a visible heading to provide a label whenever possible. The heading MAY be an instance of the standard host language heading element or an instance of an element with role heading. For host languages that support elments with the default role of region (e.g. HTML section), an explict region role must be defined to enable the heading labeling technique. If a heading is not used authors SHOULD reference a visible label with aria-labelledby if a visible label is present.

    Assistive technologies SHOULD enable users to quickly navigate to elements with role region. Mainstream user agents MAY enable users to quickly navigate to elements with role region.

    From 75c7b5d0aa5d51dd90512091e9da300f1ffcfeea Mon Sep 17 00:00:00 2001 From: Jon Date: Thu, 1 Aug 2019 11:09:45 -0500 Subject: [PATCH 07/24] updated definition of name from heading definition --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index cec891429..dbbf31230 100644 --- a/index.html +++ b/index.html @@ -533,7 +533,7 @@

    Accessible Name Calculation

  • author: name comes from values provided by the author in explicit markup features such as the aria-label attribute, the aria-labelledby attribute, or the host language labeling mechanism, such as the alt or title attributes in HTML, with HTML title attribute having the lowest precedence for specifying a text alternative.
  • contents: name comes from the text value of the element node. Although this may be allowed in addition to "author" in some roles, this is used in content only if higher priority "author" features are not provided. Priority is defined by the accessible name and description computation algorithm. [[ACCNAME-1.1]]
  • encapsulation: name comes from the text value of the element node with role label that is the closest ancestor. Although "encapsulation" may be allowed in addition to "author" and "contents" in some roles, "encapsulation" is used only if higher priority "author" features are not provided. Priority is defined by the accessible name and description computation algorithm. [[ACCNAME-1.1]]
    • -
  • heading: name comes from the text value of the first descendant element node with the role of heading. The heading can only name the closest ancestor element that allows name from heading. Although "heading" may be allowed in addition to "author" in some roles, "heading" is used in content only if higher priority "author" features are not provided. Priority is defined by the accessible name and description computation algorithm. [[ACCNAME-1.1]]
    • +
  • heading: name comes from the text value of the first descendant element node with the role of heading. A heading can only name the closest ancestor element that allows name from heading. Although "heading" may be allowed in addition to "author" in some roles, "heading" is used in content only if higher priority "author" features are not provided. Priority is defined by the accessible name and description computation algorithm. [[ACCNAME-1.1]]
  • legend: name comes from the text value of the first descendant element node with the role of legend. Although "legend" may be allowed in addition to "author" in some roles, "legend" is used in content only if higher priority "author" features are not provided. Priority is defined by the accessible name and description computation algorithm. [[ACCNAME-1.1]]
  • prohibited: the element has no name. Authors MUST NOT use the aria-label or aria-labelledby attributes to name the element.
    • From 1c5da0ede11806d839c6e3ea21418afcf230e0cc Mon Sep 17 00:00:00 2001 From: Jon Date: Thu, 1 Aug 2019 13:57:26 -0500 Subject: [PATCH 08/24] removed main element from list and restricted heading ro be first child --- index.html | 15 ++++++--------- 1 file changed, 6 insertions(+), 9 deletions(-) diff --git a/index.html b/index.html index dbbf31230..a5986d9d7 100644 --- a/index.html +++ b/index.html @@ -533,7 +533,7 @@

    Accessible Name Calculation

  • author: name comes from values provided by the author in explicit markup features such as the aria-label attribute, the aria-labelledby attribute, or the host language labeling mechanism, such as the alt or title attributes in HTML, with HTML title attribute having the lowest precedence for specifying a text alternative.
  • contents: name comes from the text value of the element node. Although this may be allowed in addition to "author" in some roles, this is used in content only if higher priority "author" features are not provided. Priority is defined by the accessible name and description computation algorithm. [[ACCNAME-1.1]]
  • encapsulation: name comes from the text value of the element node with role label that is the closest ancestor. Although "encapsulation" may be allowed in addition to "author" and "contents" in some roles, "encapsulation" is used only if higher priority "author" features are not provided. Priority is defined by the accessible name and description computation algorithm. [[ACCNAME-1.1]]
    • -
  • heading: name comes from the text value of the first descendant element node with the role of heading. A heading can only name the closest ancestor element that allows name from heading. Although "heading" may be allowed in addition to "author" in some roles, "heading" is used in content only if higher priority "author" features are not provided. Priority is defined by the accessible name and description computation algorithm. [[ACCNAME-1.1]]
    • +
  • heading: name comes from the text value of the first child element node with the role of heading. Although "heading" may be allowed in addition to "author" in some roles, "heading" is used in content only if higher priority "author" features are not provided. Priority is defined by the accessible name and description computation algorithm. [[ACCNAME-1.1]]
  • legend: name comes from the text value of the first descendant element node with the role of legend. Although "legend" may be allowed in addition to "author" in some roles, "legend" is used in content only if higher priority "author" features are not provided. Priority is defined by the accessible name and description computation algorithm. [[ACCNAME-1.1]]
  • prohibited: the element has no name. Authors MUST NOT use the aria-label or aria-labelledby attributes to name the element.
    • @@ -863,6 +863,7 @@

    Definition of Roles

    A type of dialog that contains an alert message, where initial focus goes to an element within the dialog. See related alert and dialog.

    Alert dialogs are used to convey messages to alert the user. The alertdialog role goes on the node containing both the alert message and the rest of the dialog. Content authors SHOULD make alert dialogs modal by ensuring that, while the alertdialog is shown, keyboard and mouse interactions only operate within the dialog. See aria-modal.

    Unlike alert, alertdialog can receive a response from the user. For example, to confirm that the user understands the alert being generated. When the alert dialog is displayed, authors SHOULD set focus to an active element within the alert dialog, such as a form edit field or an OK button. The user agent SHOULD fire a system alert event through the accessibility API when the alert is created, provided one is specified by the intended accessibility API.

    +

    Authors MUST give each element with role alertdialog a brief label that describes the purpose of the content in the alert dialog. Authors SHOULD use a visible heading as the first child element of the alertdialog to provide a label whenever possible. The heading MAY be an instance of the standard host language heading element or an instance of an element with role heading. If a visible label is present, but not contained in the first child element with a role of heading, authors SHOULD reference the visible label with aria-labelledby .

    Authors SHOULD use aria-describedby on an alertdialog to reference the alert message element in the dialog. If they do not, an assistive technology can resort to its internal recovery mechanism to determine the contents of the alert message.

    @@ -1044,6 +1045,7 @@

    Definition of Roles

    A section of a page that consists of a composition that forms an independent part of a document, page, or site.

    An article is not a navigational landmark, but may be nested to form a discussion where assistive technologies could pay attention to article nesting to assist the user in following the discussion. An article could be a forum post, a magazine or newspaper article, a web log entry, a user-submitted comment, or any other independent item of content. It is independent in that its contents could stand alone, for example in syndication. However, the element is still associated with its ancestors; for instance, contact information that applies to a parent body element still covers the article as well. When nesting articles, the child articles represent content that is related to the content of the parent article. For instance, a web log entry on a site that accepts user-submitted comments could represent the comments as articles nested within the article for the web log entry. Author, heading, date, or other information associated with an article does not apply to nested articles.

    When the user navigates to an element assigned the role of article, assistive technologies that typically intercept standard keyboard events SHOULD switch to document browsing mode, as opposed to passing keyboard events through to the web application. Assistive technologies MAY provide a feature allowing the user to navigate the hierarchy of any nested article elements.

    +

    Authors SHOULD give each element with role article a brief label that describes the content in the article. Authors MAY use a visible heading as the first child element of the article to provide a label. The heading MAY be an instance of the standard host language heading element or an instance of an element with role heading. If a visible label is present, but not contained in the first child element with a role of heading, authors SHOULD reference the visible label with aria-labelledby .

    When an article is in the context of a feed, the author MAY specify values for aria-posinset and aria-setsize.

    @@ -2718,7 +2720,7 @@

    Definition of Roles

    A dialog is a descendant window of the primary window of a web application. For HTML pages, the primary application window is the entire web document, i.e., the body element.

    Dialogs are most often used to prompt the user to enter or respond to information. A dialog that is designed to interrupt workflow is usually modal. See related alertdialog.

    -

    Authors SHOULD provide a dialog label, which can be done with the aria-label or aria-labelledby attribute.

    +

    Authors MUST give each element with role dialog a brief label that describes the purpose of the content in the dialog. Authors SHOULD use a visible heading as the first child element of the dialog to provide a label whenever possible. The heading MAY be an instance of the standard host language heading element or an instance of an element with role heading. If a visible label is present, but not contained in the first child element with a role of heading, authors SHOULD reference the visible label with aria-labelledby .

    Authors SHOULD ensure that all dialogs (both modal and non-modal) have at least one focusable descendant element. Authors SHOULD focus an element in the modal dialog when it is displayed, and authors SHOULD manage focus of modal dialogs.

    In the description of this role, the term "web application" does not refer to the application role, which specifies specific assistive technology behaviors.

    @@ -4800,12 +4802,7 @@

    Definition of Roles

    - + @@ -6585,7 +6582,7 @@
    Presentational Roles Conflict Resolution

    A perceivable section containing content that is relevant to a specific, author-specified purpose and sufficiently important that users will likely want to be able to navigate to the section easily and to have it listed in a summary of the page. Such a page summary could be generated dynamically by a user agent or assistive technology.

    Authors SHOULD limit use of the region role to sections containing content with a purpose that is not accurately described by one of the other landmark roles, such as main, complementary, or navigation.

    -

    Authors MUST give each element with role region a brief label that describes the purpose of the content in the region. Authors SHOULD use a visible heading to provide a label whenever possible. The heading MAY be an instance of the standard host language heading element or an instance of an element with role heading. For host languages that support elments with the default role of region (e.g. HTML section), an explict region role must be defined to enable the heading labeling technique. If a heading is not used authors SHOULD reference a visible label with aria-labelledby if a visible label is present.

    +

    Authors MUST give each element with role region a brief label that describes the purpose of the content in the region. Authors SHOULD use a visible heading as the first child element of the region to provide a label whenever possible. The heading MAY be an instance of the standard host language heading element or an instance of an element with role heading. For host languages that support elments with the default role of region (e.g. HTML section), an explict region role must be defined to enable the heading labeling technique. If a visible label is present, but not contained in the first child element with a role of heading, authors SHOULD reference the visible label with aria-labelledby .

    Assistive technologies SHOULD enable users to quickly navigate to elements with role region. Mainstream user agents MAY enable users to quickly navigate to elements with role region.

    Name From: -
      -
    • heading
      • -
    • author
      • -
    -     		author
    Accessible Name Required:
    From f5206e6842e35f1c48a14b8193c57393dc8fdfcf Mon Sep 17 00:00:00 2001 From: Jon Date: Fri, 2 Aug 2019 05:17:33 -0500 Subject: [PATCH 09/24] made the heading naming technique adpatable to requirements of naming landmakrs and other roles --- index.html | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/index.html b/index.html index a5986d9d7..bfbb79ee0 100644 --- a/index.html +++ b/index.html @@ -533,7 +533,7 @@

    Accessible Name Calculation

  • author: name comes from values provided by the author in explicit markup features such as the aria-label attribute, the aria-labelledby attribute, or the host language labeling mechanism, such as the alt or title attributes in HTML, with HTML title attribute having the lowest precedence for specifying a text alternative.
  • contents: name comes from the text value of the element node. Although this may be allowed in addition to "author" in some roles, this is used in content only if higher priority "author" features are not provided. Priority is defined by the accessible name and description computation algorithm. [[ACCNAME-1.1]]
  • encapsulation: name comes from the text value of the element node with role label that is the closest ancestor. Although "encapsulation" may be allowed in addition to "author" and "contents" in some roles, "encapsulation" is used only if higher priority "author" features are not provided. Priority is defined by the accessible name and description computation algorithm. [[ACCNAME-1.1]]
    • -
  • heading: name comes from the text value of the first child element node with the role of heading. Although "heading" may be allowed in addition to "author" in some roles, "heading" is used in content only if higher priority "author" features are not provided. Priority is defined by the accessible name and description computation algorithm. [[ACCNAME-1.1]]
    • +
  • heading: name comes from the text value of the first element node with the role of heading, with landmark roles restricted to first child node. Although "heading" may be allowed in addition to "author" in some roles, "heading" is used in content only if higher priority "author" features are not provided. Priority is defined by the accessible name and description computation algorithm. [[ACCNAME-1.1]]
  • legend: name comes from the text value of the first descendant element node with the role of legend. Although "legend" may be allowed in addition to "author" in some roles, "legend" is used in content only if higher priority "author" features are not provided. Priority is defined by the accessible name and description computation algorithm. [[ACCNAME-1.1]]
  • prohibited: the element has no name. Authors MUST NOT use the aria-label or aria-labelledby attributes to name the element.
    • @@ -863,7 +863,7 @@

    Definition of Roles

    A type of dialog that contains an alert message, where initial focus goes to an element within the dialog. See related alert and dialog.

    Alert dialogs are used to convey messages to alert the user. The alertdialog role goes on the node containing both the alert message and the rest of the dialog. Content authors SHOULD make alert dialogs modal by ensuring that, while the alertdialog is shown, keyboard and mouse interactions only operate within the dialog. See aria-modal.

    Unlike alert, alertdialog can receive a response from the user. For example, to confirm that the user understands the alert being generated. When the alert dialog is displayed, authors SHOULD set focus to an active element within the alert dialog, such as a form edit field or an OK button. The user agent SHOULD fire a system alert event through the accessibility API when the alert is created, provided one is specified by the intended accessibility API.

    -

    Authors MUST give each element with role alertdialog a brief label that describes the purpose of the content in the alert dialog. Authors SHOULD use a visible heading as the first child element of the alertdialog to provide a label whenever possible. The heading MAY be an instance of the standard host language heading element or an instance of an element with role heading. If a visible label is present, but not contained in the first child element with a role of heading, authors SHOULD reference the visible label with aria-labelledby .

    +

    Authors MUST give each element with role alertdialog a brief label that describes the purpose of the content in the alert dialog. Authors SHOULD use the first visible element with role heading of the dialog to provide a label whenever possible. The heading MAY be an instance of the standard host language heading element or an instance of an element with role heading. If a visible label is present, but not contained in the first element with a role of heading, authors SHOULD reference the visible label with aria-labelledby .

    Authors SHOULD use aria-describedby on an alertdialog to reference the alert message element in the dialog. If they do not, an assistive technology can resort to its internal recovery mechanism to determine the contents of the alert message.

    @@ -1045,7 +1045,7 @@

    Definition of Roles

    A section of a page that consists of a composition that forms an independent part of a document, page, or site.

    An article is not a navigational landmark, but may be nested to form a discussion where assistive technologies could pay attention to article nesting to assist the user in following the discussion. An article could be a forum post, a magazine or newspaper article, a web log entry, a user-submitted comment, or any other independent item of content. It is independent in that its contents could stand alone, for example in syndication. However, the element is still associated with its ancestors; for instance, contact information that applies to a parent body element still covers the article as well. When nesting articles, the child articles represent content that is related to the content of the parent article. For instance, a web log entry on a site that accepts user-submitted comments could represent the comments as articles nested within the article for the web log entry. Author, heading, date, or other information associated with an article does not apply to nested articles.

    When the user navigates to an element assigned the role of article, assistive technologies that typically intercept standard keyboard events SHOULD switch to document browsing mode, as opposed to passing keyboard events through to the web application. Assistive technologies MAY provide a feature allowing the user to navigate the hierarchy of any nested article elements.

    -

    Authors SHOULD give each element with role article a brief label that describes the content in the article. Authors MAY use a visible heading as the first child element of the article to provide a label. The heading MAY be an instance of the standard host language heading element or an instance of an element with role heading. If a visible label is present, but not contained in the first child element with a role of heading, authors SHOULD reference the visible label with aria-labelledby .

    +

    Authors SHOULD give each element with role article a brief label that describes the content in the article. Authors SHOULD use a visible heading as the first heading of the article to provide a label. The heading MAY be an instance of the standard host language heading element or an instance of an element with role heading. If a visible label is present, but not contained in the first element with a role of heading, authors SHOULD reference the visible label with aria-labelledby .

    When an article is in the context of a feed, the author MAY specify values for aria-posinset and aria-setsize.

    @@ -2326,6 +2326,7 @@

    Definition of Roles

    A supporting section of the document, designed to be complementary to the main content at a similar level in the DOM hierarchy, but remains meaningful when separated from the main content.

    There are various types of content that would appropriately have this role. For example, in the case of a portal, this may include but not be limited to show times, current weather, related articles, or stocks to watch. The complementary role indicates that contained content is relevant to the main content. If the complementary content is completely separable from the main content, it may be appropriate to use a more general role.

    +

    If authors provide more than one element with the role complementary on a page, authors SHOULD give each complementary region a brief label that describes the purpose of the content in the region. Authors SHOULD use a visible heading as the first child element of the region to provide a label whenever possible. The heading MAY be an instance of the standard host language heading element or an instance of an element with role heading. If a visible label is present, but not contained in the first child element with a role of heading, authors SHOULD reference the visible label with aria-labelledby .

    User agents SHOULD treat elements with the role of complementary as navigational landmarks.

    @@ -2720,7 +2721,7 @@

    Definition of Roles

    A dialog is a descendant window of the primary window of a web application. For HTML pages, the primary application window is the entire web document, i.e., the body element.

    Dialogs are most often used to prompt the user to enter or respond to information. A dialog that is designed to interrupt workflow is usually modal. See related alertdialog.

    -

    Authors MUST give each element with role dialog a brief label that describes the purpose of the content in the dialog. Authors SHOULD use a visible heading as the first child element of the dialog to provide a label whenever possible. The heading MAY be an instance of the standard host language heading element or an instance of an element with role heading. If a visible label is present, but not contained in the first child element with a role of heading, authors SHOULD reference the visible label with aria-labelledby .

    +

    Authors MUST give each element with role dialog a brief label that describes the purpose of the content in the dialog. Authors SHOULD use the first visible element with role heading of the dialog to provide a label whenever possible. The heading MAY be an instance of the standard host language heading element or an instance of an element with role heading. If a visible label is present, but not contained in the first element with a role of heading, authors SHOULD reference the visible label with aria-labelledby .

    Authors SHOULD ensure that all dialogs (both modal and non-modal) have at least one focusable descendant element. Authors SHOULD focus an element in the modal dialog when it is displayed, and authors SHOULD manage focus of modal dialogs.

    In the description of this role, the term "web application" does not refer to the application role, which specifies specific assistive technology behaviors.

    @@ -5619,6 +5620,7 @@

    Plain HTML or Polyfill DOM Result of the MathML Quadratic Formula

    navigation

    A collection of navigational elements (usually links) for navigating the document or related documents.

    +

    If authors provide more than one element with the role navigation on a page, authors SHOULD give each navigation region a brief label that describes the purpose of the content in the region. Authors SHOULD use a visible or offscreen heading as the first child element of the region to provide a label whenever possible. The heading MAY be an instance of the standard host language heading element or an instance of an element with role heading. If a visible or offscreen label is present, but not contained in the first child element with a role of heading, authors SHOULD reference the visible label with aria-labelledby .

    User agents SHOULD treat elements with the role of navigation as navigational landmarks.

    @@ -6582,7 +6584,7 @@
    Presentational Roles Conflict Resolution

    A perceivable section containing content that is relevant to a specific, author-specified purpose and sufficiently important that users will likely want to be able to navigate to the section easily and to have it listed in a summary of the page. Such a page summary could be generated dynamically by a user agent or assistive technology.

    Authors SHOULD limit use of the region role to sections containing content with a purpose that is not accurately described by one of the other landmark roles, such as main, complementary, or navigation.

    -

    Authors MUST give each element with role region a brief label that describes the purpose of the content in the region. Authors SHOULD use a visible heading as the first child element of the region to provide a label whenever possible. The heading MAY be an instance of the standard host language heading element or an instance of an element with role heading. For host languages that support elments with the default role of region (e.g. HTML section), an explict region role must be defined to enable the heading labeling technique. If a visible label is present, but not contained in the first child element with a role of heading, authors SHOULD reference the visible label with aria-labelledby .

    +

    Authors MUST give each element with role region a brief label that describes the purpose of the content in the region. Authors SHOULD use a visible heading as the first child element of the region to provide a label whenever possible. The heading MAY be an instance of the standard host language heading element or an instance of an element with role heading. For host languages that support elments with the default role of region (e.g. HTML section), an explict region role must be defined (e.g. role=region) to enable the heading labeling technique. If a visible label is present, but not contained in the first child element with a role of heading, authors SHOULD reference the visible label with aria-labelledby .

    Assistive technologies SHOULD enable users to quickly navigate to elements with role region. Mainstream user agents MAY enable users to quickly navigate to elements with role region.

    From aea75f6d59268fe1e28c8656fce2fd3074518e61 Mon Sep 17 00:00:00 2001 From: Jon Date: Fri, 2 Aug 2019 05:34:17 -0500 Subject: [PATCH 10/24] added restructoin to only naming nearest ancestor --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index bfbb79ee0..1e9070f8a 100644 --- a/index.html +++ b/index.html @@ -533,7 +533,7 @@

    Accessible Name Calculation

  • author: name comes from values provided by the author in explicit markup features such as the aria-label attribute, the aria-labelledby attribute, or the host language labeling mechanism, such as the alt or title attributes in HTML, with HTML title attribute having the lowest precedence for specifying a text alternative.
  • contents: name comes from the text value of the element node. Although this may be allowed in addition to "author" in some roles, this is used in content only if higher priority "author" features are not provided. Priority is defined by the accessible name and description computation algorithm. [[ACCNAME-1.1]]
  • encapsulation: name comes from the text value of the element node with role label that is the closest ancestor. Although "encapsulation" may be allowed in addition to "author" and "contents" in some roles, "encapsulation" is used only if higher priority "author" features are not provided. Priority is defined by the accessible name and description computation algorithm. [[ACCNAME-1.1]]
    • -
  • heading: name comes from the text value of the first element node with the role of heading, with landmark roles restricted to first child node. Although "heading" may be allowed in addition to "author" in some roles, "heading" is used in content only if higher priority "author" features are not provided. Priority is defined by the accessible name and description computation algorithm. [[ACCNAME-1.1]]
    • +
  • heading: name comes from the text value of the first element node with the role of heading, with landmark roles restricted to first child node. A heading can only be used to name its nearest ancestor element that allows name from heading. Although "heading" may be allowed in addition to "author" in some roles, "heading" is used in content only if higher priority "author" features are not provided. Priority is defined by the accessible name and description computation algorithm. [[ACCNAME-1.1]]
  • legend: name comes from the text value of the first descendant element node with the role of legend. Although "legend" may be allowed in addition to "author" in some roles, "legend" is used in content only if higher priority "author" features are not provided. Priority is defined by the accessible name and description computation algorithm. [[ACCNAME-1.1]]
  • prohibited: the element has no name. Authors MUST NOT use the aria-label or aria-labelledby attributes to name the element.
    • From 487fb4f3d2053c865ff7ccbc93a35c7547e67ce4 Mon Sep 17 00:00:00 2001 From: Jon Date: Fri, 2 Aug 2019 10:01:53 -0500 Subject: [PATCH 11/24] clarified first descentant element with role heading using depth first search --- index.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/index.html b/index.html index 1e9070f8a..5ac02df79 100644 --- a/index.html +++ b/index.html @@ -533,7 +533,7 @@

    Accessible Name Calculation

  • author: name comes from values provided by the author in explicit markup features such as the aria-label attribute, the aria-labelledby attribute, or the host language labeling mechanism, such as the alt or title attributes in HTML, with HTML title attribute having the lowest precedence for specifying a text alternative.
  • contents: name comes from the text value of the element node. Although this may be allowed in addition to "author" in some roles, this is used in content only if higher priority "author" features are not provided. Priority is defined by the accessible name and description computation algorithm. [[ACCNAME-1.1]]
  • encapsulation: name comes from the text value of the element node with role label that is the closest ancestor. Although "encapsulation" may be allowed in addition to "author" and "contents" in some roles, "encapsulation" is used only if higher priority "author" features are not provided. Priority is defined by the accessible name and description computation algorithm. [[ACCNAME-1.1]]
    • -
  • heading: name comes from the text value of the first element node with the role of heading, with landmark roles restricted to first child node. A heading can only be used to name its nearest ancestor element that allows name from heading. Although "heading" may be allowed in addition to "author" in some roles, "heading" is used in content only if higher priority "author" features are not provided. Priority is defined by the accessible name and description computation algorithm. [[ACCNAME-1.1]]
    • +
  • heading: name comes from the text value of the first descendant (i.e. depth first) element node with the role of heading, with landmark roles heading elements used for naming are restricted to first child node. A heading can only be used to name its nearest ancestor element that allows name from heading. Although "heading" may be allowed in addition to "author" in some roles, "heading" is used in content only if higher priority "author" features are not provided. Priority is defined by the accessible name and description computation algorithm. [[ACCNAME-1.1]]
  • legend: name comes from the text value of the first descendant element node with the role of legend. Although "legend" may be allowed in addition to "author" in some roles, "legend" is used in content only if higher priority "author" features are not provided. Priority is defined by the accessible name and description computation algorithm. [[ACCNAME-1.1]]
  • prohibited: the element has no name. Authors MUST NOT use the aria-label or aria-labelledby attributes to name the element.
    • @@ -1045,7 +1045,7 @@

    Definition of Roles

    A section of a page that consists of a composition that forms an independent part of a document, page, or site.

    An article is not a navigational landmark, but may be nested to form a discussion where assistive technologies could pay attention to article nesting to assist the user in following the discussion. An article could be a forum post, a magazine or newspaper article, a web log entry, a user-submitted comment, or any other independent item of content. It is independent in that its contents could stand alone, for example in syndication. However, the element is still associated with its ancestors; for instance, contact information that applies to a parent body element still covers the article as well. When nesting articles, the child articles represent content that is related to the content of the parent article. For instance, a web log entry on a site that accepts user-submitted comments could represent the comments as articles nested within the article for the web log entry. Author, heading, date, or other information associated with an article does not apply to nested articles.

    When the user navigates to an element assigned the role of article, assistive technologies that typically intercept standard keyboard events SHOULD switch to document browsing mode, as opposed to passing keyboard events through to the web application. Assistive technologies MAY provide a feature allowing the user to navigate the hierarchy of any nested article elements.

    -

    Authors SHOULD give each element with role article a brief label that describes the content in the article. Authors SHOULD use a visible heading as the first heading of the article to provide a label. The heading MAY be an instance of the standard host language heading element or an instance of an element with role heading. If a visible label is present, but not contained in the first element with a role of heading, authors SHOULD reference the visible label with aria-labelledby .

    +

    Authors SHOULD give each element with role article a brief label that describes the content in the article. Authors SHOULD use a visible heading as the first descendant (e.g. depth first) heading of the article to provide a label. The heading MAY be an instance of the standard host language heading element or an instance of an element with role heading. If a visible label is present, but not contained in the first element with a role of heading, authors SHOULD reference the visible label with aria-labelledby .

    When an article is in the context of a feed, the author MAY specify values for aria-posinset and aria-setsize.

    From 5ceb22325f7456d37039adcac3d379c68042b261 Mon Sep 17 00:00:00 2001 From: James Craig Date: Thu, 15 Sep 2022 17:31:15 -0700 Subject: [PATCH 12/24] Apply suggestions from code review WG consensus changes from 15 Sept 2022 TPAC F2F in Vancouver --- index.html | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/index.html b/index.html index 5ac02df79..fb241f091 100644 --- a/index.html +++ b/index.html @@ -533,7 +533,7 @@

    Accessible Name Calculation

  • author: name comes from values provided by the author in explicit markup features such as the aria-label attribute, the aria-labelledby attribute, or the host language labeling mechanism, such as the alt or title attributes in HTML, with HTML title attribute having the lowest precedence for specifying a text alternative.
  • contents: name comes from the text value of the element node. Although this may be allowed in addition to "author" in some roles, this is used in content only if higher priority "author" features are not provided. Priority is defined by the accessible name and description computation algorithm. [[ACCNAME-1.1]]
  • encapsulation: name comes from the text value of the element node with role label that is the closest ancestor. Although "encapsulation" may be allowed in addition to "author" and "contents" in some roles, "encapsulation" is used only if higher priority "author" features are not provided. Priority is defined by the accessible name and description computation algorithm. [[ACCNAME-1.1]]
    • -
  • heading: name comes from the text value of the first descendant (i.e. depth first) element node with the role of heading, with landmark roles heading elements used for naming are restricted to first child node. A heading can only be used to name its nearest ancestor element that allows name from heading. Although "heading" may be allowed in addition to "author" in some roles, "heading" is used in content only if higher priority "author" features are not provided. Priority is defined by the accessible name and description computation algorithm. [[ACCNAME-1.1]]
    • +
  • heading: name comes from the text value of the first descendant (i.e. depth first) element node with the role of heading. Although "heading" may be allowed in addition to "author" in some roles, "heading" is used in content only if higher priority "author" features are not provided. Priority is defined by the accessible name and description computation algorithm. [[ACCNAME-1.1]]
  • legend: name comes from the text value of the first descendant element node with the role of legend. Although "legend" may be allowed in addition to "author" in some roles, "legend" is used in content only if higher priority "author" features are not provided. Priority is defined by the accessible name and description computation algorithm. [[ACCNAME-1.1]]
  • prohibited: the element has no name. Authors MUST NOT use the aria-label or aria-labelledby attributes to name the element.
    • @@ -924,8 +924,8 @@

    Definition of Roles

     @@ -1106,8 +1106,8 @@

    Definition of Roles

    @@ -2382,8 +2382,8 @@

    Definition of Roles

    @@ -2721,7 +2721,6 @@

    Definition of Roles

    A dialog is a descendant window of the primary window of a web application. For HTML pages, the primary application window is the entire web document, i.e., the body element.

    Dialogs are most often used to prompt the user to enter or respond to information. A dialog that is designed to interrupt workflow is usually modal. See related alertdialog.

    -

    Authors MUST give each element with role dialog a brief label that describes the purpose of the content in the dialog. Authors SHOULD use the first visible element with role heading of the dialog to provide a label whenever possible. The heading MAY be an instance of the standard host language heading element or an instance of an element with role heading. If a visible label is present, but not contained in the first element with a role of heading, authors SHOULD reference the visible label with aria-labelledby .

    Authors SHOULD ensure that all dialogs (both modal and non-modal) have at least one focusable descendant element. Authors SHOULD focus an element in the modal dialog when it is displayed, and authors SHOULD manage focus of modal dialogs.

    In the description of this role, the term "web application" does not refer to the application role, which specifies specific assistive technology behaviors.

    @@ -2778,8 +2777,8 @@

    Definition of Roles

    @@ -5676,8 +5675,8 @@

    Plain HTML or Polyfill DOM Result of the MathML Quadratic Formula

    @@ -6642,8 +6641,8 @@
    Presentational Roles Conflict Resolution
    From 10b90f57d100ddc0708f20fe5edf71e31bbf6ea7 Mon Sep 17 00:00:00 2001 From: James Craig Date: Thu, 15 Sep 2022 22:58:04 -0700 Subject: [PATCH 13/24] testing whitespace cruft correction in the GH interface --- common/script/aria.js | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/common/script/aria.js b/common/script/aria.js index 69d25aa8f..2c24979cb 100644 --- a/common/script/aria.js +++ b/common/script/aria.js @@ -352,7 +352,7 @@ require(["core/pubsubhub"], function( respecEvents ) { if (node.textContent.indexOf("author") !== -1) { fromAuthor += "
  • " + content + "" + req + "
    • "; - } + } if (!isAbstract && node.textContent.indexOf("content") !== -1) { fromContent += "
  • " + content + "" + "
    • "; } From cd7cc12fd660d1e13c7327289df2e1c568c69067 Mon Sep 17 00:00:00 2001 From: James Craig Date: Thu, 15 Sep 2022 22:59:06 -0700 Subject: [PATCH 14/24] m. test whitespace diff correction --- common/script/aria.js | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/common/script/aria.js b/common/script/aria.js index 2c24979cb..063502928 100644 --- a/common/script/aria.js +++ b/common/script/aria.js @@ -125,7 +125,7 @@ require(["core/pubsubhub"], function( respecEvents ) { }) ; } - + } ; var s = "var roleInfo = " + JSON.stringify(roleInfo, null, '\t') ; From c03c01de8410a8b6ec13c8f3971c9abbc0cd438a Mon Sep 17 00:00:00 2001 From: James Craig Date: Thu, 15 Sep 2022 23:15:16 -0700 Subject: [PATCH 15/24] Apply suggestions from code review Batch revert the whitespace diffs in this PR --- common/script/aria.js | 32 ++++++++++++------------- index.html | 54 +++++++++++++++++++++---------------------- 2 files changed, 43 insertions(+), 43 deletions(-) diff --git a/common/script/aria.js b/common/script/aria.js index 063502928..dc1174cff 100644 --- a/common/script/aria.js +++ b/common/script/aria.js @@ -173,11 +173,11 @@ require(["core/pubsubhub"], function( respecEvents ) { var abstract = container.querySelector("." + type + "-applicability"); if ((abstract.textContent || abstract.innerText) === "All elements of the base markup") { globalSP.push({ is: type, title: title, name: content, desc: desc, prohibited: false }); - } + } else if ((abstract.textContent || abstract.innerText) === "All elements of the base markup except for some roles or elements that prohibit its use") { globalSP.push({ is: type, title: title, name: content, desc: desc, prohibited: true }); - } - + } + // the rdef is gone. if we are in a div, convert that div to a section if (container.nodeName.toLowerCase() == "div") { @@ -192,7 +192,7 @@ require(["core/pubsubhub"], function( respecEvents ) { container.parentNode.replaceChild(sec, container) ; } }); - + if (!skipIndex) { // we have all the properties and states - spit out the // index @@ -318,7 +318,7 @@ require(["core/pubsubhub"], function( respecEvents ) { parentRoles.push(s); }); } - // are there supported states / properties in this role? + // are there supported states / properties in this role? var attrs = []; $.each(container.querySelectorAll(".role-properties, .role-required-properties, .role-disallowed"), function(i, node) { if (node && ((node.textContent && node.textContent.length !== 1) || (node.innerText && node.innerText.length !== 1))) { @@ -331,8 +331,8 @@ require(["core/pubsubhub"], function( respecEvents ) { var type = (item.localName === "pref" ? "property" : "state"); var req = $(node).hasClass("role-required-properties"); var dis = $(node).hasClass("role-disallowed"); - attrs.push( { is: type, name: name, required: req, disallowed: dis } ); - + attrs.push( { is: type, name: name, required: req, disallowed: dis } ); + // remember that the state or property is // referenced by this role propList[name].roles.push(title); @@ -360,7 +360,7 @@ require(["core/pubsubhub"], function( respecEvents ) { fromProhibited += "
  • " + content + "" + req + "
    • "; } if (node.textContent.indexOf("encapsulation") !== -1) { - fromEncapsulation += "
  • " + content + "" + req + "
    • "; + fromEncapsulation += "
  • " + content + "" + req + "
    • "; } if (node.textContent.indexOf("legend") !== -1) { fromLegend += "
  • " + content + "" + req + "
    • "; @@ -400,7 +400,7 @@ require(["core/pubsubhub"], function( respecEvents ) { return myList; } }; - + if (!skipIndex) { // build up the complete inherited SP lists for each role // however, if the role already specifies an item, do not include it @@ -449,7 +449,7 @@ require(["core/pubsubhub"], function( respecEvents ) { } } }); - + // Update state and property role references var getAllSubRoles = function(role) { var ref = subRoles[role]; @@ -468,7 +468,7 @@ require(["core/pubsubhub"], function( respecEvents ) { return []; } }; - + $.each(propList, function(i, item) { var output = ""; var section = document.querySelector("#" + item.name); @@ -515,7 +515,7 @@ require(["core/pubsubhub"], function( respecEvents ) { } } }); - + // spit out the index var node = document.getElementById("index_role"); var parentNode = node.parentNode; @@ -607,15 +607,15 @@ require(["core/pubsubhub"], function( respecEvents ) { } // prune out unused rows throughout the document - + $.each(document.querySelectorAll(".role-abstract, .role-parent, .role-base, .role-related, .role-scope, .role-mustcontain, .role-required-properties, .role-properties, .role-namefrom, .role-namerequired, .role-namerequired-inherited, .role-childpresentational, .role-presentational-inherited, .state-related, .property-related,.role-inherited, .role-children, .property-descendants, .state-descendants, .implicit-values"), function(i, item) { var content = $(item).text(); if (content.length === 1 || content.length === 0) { // there is no item - remove the row item.parentNode.remove(); - } else if (content === "Placeholder" - && !skipIndex - && (item.className === "role-inherited" + } else if (content === "Placeholder" + && !skipIndex + && (item.className === "role-inherited" || item.className === "role-children" || item.className === "property-descendants" || item.className === "state-descendants" )) { diff --git a/index.html b/index.html index fb241f091..4575e926f 100644 --- a/index.html +++ b/index.html @@ -494,7 +494,7 @@

    Inherited States and Properties

    Prohibited States and Properties

    List of states and properties that are prohibited on a role. Authors MUST NOT specify a prohibited state or property.

    A host language attribute with the appropriate implicit WAI-ARIA semantic would also prohibit a state or property in this section.

    - +

    Required Owned Elements

    @@ -574,7 +574,7 @@

    Roles Supporting Name from Heading

    Roles Supporting Name from Legend

    -
    +

    Roles which cannot be named (Name prohibited)

    @@ -1536,7 +1536,7 @@

    Definition of Roles

     - + @@ -1712,9 +1712,9 @@

    Definition of Roles

    • aria-label
    • aria-labelledby
      • -
    + - + @@ -1998,9 +1998,9 @@

    Definition of Roles

    • aria-label
    • aria-labelledby
      • -
    + - + @@ -2690,9 +2690,9 @@

    Definition of Roles

    • aria-label
    • aria-labelledby
      • -
    + - + @@ -3020,9 +3020,9 @@

    Definition of Roles

    • aria-label
    • aria-labelledby
      • -
    + - + @@ -3357,9 +3357,9 @@

    Definition of Roles

    • aria-label
    • aria-labelledby
      • -
    + - + @@ -3958,7 +3958,7 @@

    Definition of Roles

    - + @@ -3969,9 +3969,9 @@

    Definition of Roles

    • aria-label
    • aria-labelledby
      • -
    + - + @@ -6045,9 +6045,9 @@
    Note regarding the ARIA 1.1 none role.
    • aria-label
    • aria-labelledby
      • -
    + - + @@ -6205,9 +6205,9 @@
    Presentational Roles Conflict Resolution
    • aria-label
    • aria-labelledby
      • -
    + - + @@ -8002,9 +8002,9 @@
    Presentational Roles Conflict Resolution
    • aria-label
    • aria-labelledby
      • -
    + - + @@ -8164,9 +8164,9 @@
    Presentational Roles Conflict Resolution
    • aria-label
    • aria-labelledby
      • -
    + - + @@ -8251,9 +8251,9 @@
    Presentational Roles Conflict Resolution
    • aria-label
    • aria-labelledby
      • -
    + - + @@ -12878,7 +12878,7 @@

    States and Properties

  • Otherwise, ignore the value and treat the property as not present.
    • - +

    In UIA, the user agent might leave the corresponding property set to "unsupported."

    User agents MUST NOT expose WAI-ARIA attributes that reference unresolved IDs. For example:

      From 6d88243b21748461f4cee34f3920f70931e59d04 Mon Sep 17 00:00:00 2001 From: James Craig Date: Thu, 15 Sep 2022 23:17:22 -0700 Subject: [PATCH 16/24] m. missed one errant whitespace diff --- common/script/aria.js | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/common/script/aria.js b/common/script/aria.js index dc1174cff..871e74df4 100644 --- a/common/script/aria.js +++ b/common/script/aria.js @@ -192,7 +192,7 @@ require(["core/pubsubhub"], function( respecEvents ) { container.parentNode.replaceChild(sec, container) ; } }); - + if (!skipIndex) { // we have all the properties and states - spit out the // index From 932765b174a9b235cc925e6002bc59c857a07408 Mon Sep 17 00:00:00 2001 From: James Craig Date: Fri, 7 Oct 2022 17:06:34 -0700 Subject: [PATCH 17/24] Apply suggestions from code review Trying to get a clean diff with all the previously discussed changes, before recycling all the review requests. --- index.html | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/index.html b/index.html index 4575e926f..46930b695 100644 --- a/index.html +++ b/index.html @@ -569,7 +569,7 @@

      Roles Supporting Name from Encapsulation

      Roles Supporting Name from Heading

      - +

      Roles Supporting Name from Legend

      @@ -863,7 +863,7 @@

      Definition of Roles

      A type of dialog that contains an alert message, where initial focus goes to an element within the dialog. See related alert and dialog.

      Alert dialogs are used to convey messages to alert the user. The alertdialog role goes on the node containing both the alert message and the rest of the dialog. Content authors SHOULD make alert dialogs modal by ensuring that, while the alertdialog is shown, keyboard and mouse interactions only operate within the dialog. See aria-modal.

      Unlike alert, alertdialog can receive a response from the user. For example, to confirm that the user understands the alert being generated. When the alert dialog is displayed, authors SHOULD set focus to an active element within the alert dialog, such as a form edit field or an OK button. The user agent SHOULD fire a system alert event through the accessibility API when the alert is created, provided one is specified by the intended accessibility API.

      -

      Authors MUST give each element with role alertdialog a brief label that describes the purpose of the content in the alert dialog. Authors SHOULD use the first visible element with role heading of the dialog to provide a label whenever possible. The heading MAY be an instance of the standard host language heading element or an instance of an element with role heading. If a visible label is present, but not contained in the first element with a role of heading, authors SHOULD reference the visible label with aria-labelledby .

      +

      Authors MUST give each element with role alertdialog a brief label that describes the purpose of the content in the alert dialog. Authors SHOULD use the first visible element of the dialog with an explicit or implicit role of heading to provide a label. If a visible label is present, but not contained in the first element with a role of heading, authors SHOULD reference the visible label with aria-labelledby.

      Authors SHOULD use aria-describedby on an alertdialog to reference the alert message element in the dialog. If they do not, an assistive technology can resort to its internal recovery mechanism to determine the contents of the alert message.

    Name From:
      -
    • heading
    • author
      • +
    • heading
    Name From:
      -
    • heading
    • author
      • +
    • heading
    Name From:
      -
    • heading
    • author
      • +
    • heading
    Name From:
      -
    • heading
    • author
      • +
    • heading
    Name From:
      -
    • heading
    • author
      • +
    • heading
    Name From:
      -
    • heading
    • author
      • +
    • heading
    Inherited States and Properties: Placeholder
    Name From: author
    Name From: prohibited
    Name From: prohibited
    Name From: prohibited
    Name From: prohibited
    Name From: prohibited
    Supported States and Properties:
    Inherited States and Properties: Placeholder
    Name From: prohibited
    Name From: prohibited
    Name From: prohibited
    Name From: prohibited
    Name From: prohibited
    Name From: prohibited
    @@ -1045,7 +1045,6 @@

    Definition of Roles

    A section of a page that consists of a composition that forms an independent part of a document, page, or site.

    An article is not a navigational landmark, but may be nested to form a discussion where assistive technologies could pay attention to article nesting to assist the user in following the discussion. An article could be a forum post, a magazine or newspaper article, a web log entry, a user-submitted comment, or any other independent item of content. It is independent in that its contents could stand alone, for example in syndication. However, the element is still associated with its ancestors; for instance, contact information that applies to a parent body element still covers the article as well. When nesting articles, the child articles represent content that is related to the content of the parent article. For instance, a web log entry on a site that accepts user-submitted comments could represent the comments as articles nested within the article for the web log entry. Author, heading, date, or other information associated with an article does not apply to nested articles.

    When the user navigates to an element assigned the role of article, assistive technologies that typically intercept standard keyboard events SHOULD switch to document browsing mode, as opposed to passing keyboard events through to the web application. Assistive technologies MAY provide a feature allowing the user to navigate the hierarchy of any nested article elements.

    -

    Authors SHOULD give each element with role article a brief label that describes the content in the article. Authors SHOULD use a visible heading as the first descendant (e.g. depth first) heading of the article to provide a label. The heading MAY be an instance of the standard host language heading element or an instance of an element with role heading. If a visible label is present, but not contained in the first element with a role of heading, authors SHOULD reference the visible label with aria-labelledby .

    When an article is in the context of a feed, the author MAY specify values for aria-posinset and aria-setsize.

    @@ -5619,7 +5618,6 @@

    Plain HTML or Polyfill DOM Result of the MathML Quadratic Formula

    navigation

    A collection of navigational elements (usually links) for navigating the document or related documents.

    -

    If authors provide more than one element with the role navigation on a page, authors SHOULD give each navigation region a brief label that describes the purpose of the content in the region. Authors SHOULD use a visible or offscreen heading as the first child element of the region to provide a label whenever possible. The heading MAY be an instance of the standard host language heading element or an instance of an element with role heading. If a visible or offscreen label is present, but not contained in the first child element with a role of heading, authors SHOULD reference the visible label with aria-labelledby .

    User agents SHOULD treat elements with the role of navigation as navigational landmarks.

    @@ -6583,7 +6581,7 @@
    Presentational Roles Conflict Resolution

    A perceivable section containing content that is relevant to a specific, author-specified purpose and sufficiently important that users will likely want to be able to navigate to the section easily and to have it listed in a summary of the page. Such a page summary could be generated dynamically by a user agent or assistive technology.

    Authors SHOULD limit use of the region role to sections containing content with a purpose that is not accurately described by one of the other landmark roles, such as main, complementary, or navigation.

    -

    Authors MUST give each element with role region a brief label that describes the purpose of the content in the region. Authors SHOULD use a visible heading as the first child element of the region to provide a label whenever possible. The heading MAY be an instance of the standard host language heading element or an instance of an element with role heading. For host languages that support elments with the default role of region (e.g. HTML section), an explict region role must be defined (e.g. role=region) to enable the heading labeling technique. If a visible label is present, but not contained in the first child element with a role of heading, authors SHOULD reference the visible label with aria-labelledby .

    +

    Authors MUST give each element with role region a brief label that describes the purpose of the content in the region. For host languages that support elments with the default role of region (e.g. HTML section), an explict region role must be defined (e.g. role="region") to enable the nameFrom: heading technique.

    Assistive technologies SHOULD enable users to quickly navigate to elements with role region. Mainstream user agents MAY enable users to quickly navigate to elements with role region.

    From 14c1f8eea4e611ccac49e9618805cdbc5ce59ba2 Mon Sep 17 00:00:00 2001 From: James Craig Date: Fri, 7 Oct 2022 17:10:04 -0700 Subject: [PATCH 18/24] pulling inessentials out of the diff before re-requesting reviews --- index.html | 1 - 1 file changed, 1 deletion(-) diff --git a/index.html b/index.html index 46930b695..abf184624 100644 --- a/index.html +++ b/index.html @@ -2325,7 +2325,6 @@

    Definition of Roles

    A supporting section of the document, designed to be complementary to the main content at a similar level in the DOM hierarchy, but remains meaningful when separated from the main content.

    There are various types of content that would appropriately have this role. For example, in the case of a portal, this may include but not be limited to show times, current weather, related articles, or stocks to watch. The complementary role indicates that contained content is relevant to the main content. If the complementary content is completely separable from the main content, it may be appropriate to use a more general role.

    -

    If authors provide more than one element with the role complementary on a page, authors SHOULD give each complementary region a brief label that describes the purpose of the content in the region. Authors SHOULD use a visible heading as the first child element of the region to provide a label whenever possible. The heading MAY be an instance of the standard host language heading element or an instance of an element with role heading. If a visible label is present, but not contained in the first child element with a role of heading, authors SHOULD reference the visible label with aria-labelledby .

    User agents SHOULD treat elements with the role of complementary as navigational landmarks.

    From fca02626ced3095439864a530c2af52d226548f7 Mon Sep 17 00:00:00 2001 From: James Craig Date: Fri, 7 Oct 2022 17:11:33 -0700 Subject: [PATCH 19/24] extra whitespace included in new line --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index abf184624..e0cbd68df 100644 --- a/index.html +++ b/index.html @@ -533,7 +533,7 @@

    Accessible Name Calculation

  • author: name comes from values provided by the author in explicit markup features such as the aria-label attribute, the aria-labelledby attribute, or the host language labeling mechanism, such as the alt or title attributes in HTML, with HTML title attribute having the lowest precedence for specifying a text alternative.
  • contents: name comes from the text value of the element node. Although this may be allowed in addition to "author" in some roles, this is used in content only if higher priority "author" features are not provided. Priority is defined by the accessible name and description computation algorithm. [[ACCNAME-1.1]]
  • encapsulation: name comes from the text value of the element node with role label that is the closest ancestor. Although "encapsulation" may be allowed in addition to "author" and "contents" in some roles, "encapsulation" is used only if higher priority "author" features are not provided. Priority is defined by the accessible name and description computation algorithm. [[ACCNAME-1.1]]
    • -
  • heading: name comes from the text value of the first descendant (i.e. depth first) element node with the role of heading. Although "heading" may be allowed in addition to "author" in some roles, "heading" is used in content only if higher priority "author" features are not provided. Priority is defined by the accessible name and description computation algorithm. [[ACCNAME-1.1]]
    • +
  • heading: name comes from the text value of the first descendant (i.e. depth first) element node with the role of heading. Although "heading" may be allowed in addition to "author" in some roles, "heading" is used in content only if higher priority "author" features are not provided. Priority is defined by the accessible name and description computation algorithm. [[ACCNAME-1.1]]
  • legend: name comes from the text value of the first descendant element node with the role of legend. Although "legend" may be allowed in addition to "author" in some roles, "legend" is used in content only if higher priority "author" features are not provided. Priority is defined by the accessible name and description computation algorithm. [[ACCNAME-1.1]]
  • prohibited: the element has no name. Authors MUST NOT use the aria-label or aria-labelledby attributes to name the element.
    • From 0b6697bd14368b495442a613c850a00b682fcfe5 Mon Sep 17 00:00:00 2001 From: James Craig Date: Fri, 7 Oct 2022 17:14:51 -0700 Subject: [PATCH 20/24] deleting excess --- index.html | 1 - 1 file changed, 1 deletion(-) diff --git a/index.html b/index.html index e0cbd68df..78509cdd9 100644 --- a/index.html +++ b/index.html @@ -863,7 +863,6 @@

    Definition of Roles

    A type of dialog that contains an alert message, where initial focus goes to an element within the dialog. See related alert and dialog.

    Alert dialogs are used to convey messages to alert the user. The alertdialog role goes on the node containing both the alert message and the rest of the dialog. Content authors SHOULD make alert dialogs modal by ensuring that, while the alertdialog is shown, keyboard and mouse interactions only operate within the dialog. See aria-modal.

    Unlike alert, alertdialog can receive a response from the user. For example, to confirm that the user understands the alert being generated. When the alert dialog is displayed, authors SHOULD set focus to an active element within the alert dialog, such as a form edit field or an OK button. The user agent SHOULD fire a system alert event through the accessibility API when the alert is created, provided one is specified by the intended accessibility API.

    -

    Authors MUST give each element with role alertdialog a brief label that describes the purpose of the content in the alert dialog. Authors SHOULD use the first visible element of the dialog with an explicit or implicit role of heading to provide a label. If a visible label is present, but not contained in the first element with a role of heading, authors SHOULD reference the visible label with aria-labelledby.

    Authors SHOULD use aria-describedby on an alertdialog to reference the alert message element in the dialog. If they do not, an assistive technology can resort to its internal recovery mechanism to determine the contents of the alert message.

    From 455274f06b39810e0a7ebf0b49a444fe51dd52b3 Mon Sep 17 00:00:00 2001 From: James Craig Date: Wed, 25 Jan 2023 14:21:32 -0800 Subject: [PATCH 21/24] m. ed nit Co-authored-by: Scott O'Hara --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index 78509cdd9..8d4b037e8 100644 --- a/index.html +++ b/index.html @@ -533,7 +533,7 @@

    Accessible Name Calculation

  • author: name comes from values provided by the author in explicit markup features such as the aria-label attribute, the aria-labelledby attribute, or the host language labeling mechanism, such as the alt or title attributes in HTML, with HTML title attribute having the lowest precedence for specifying a text alternative.
  • contents: name comes from the text value of the element node. Although this may be allowed in addition to "author" in some roles, this is used in content only if higher priority "author" features are not provided. Priority is defined by the accessible name and description computation algorithm. [[ACCNAME-1.1]]
  • encapsulation: name comes from the text value of the element node with role label that is the closest ancestor. Although "encapsulation" may be allowed in addition to "author" and "contents" in some roles, "encapsulation" is used only if higher priority "author" features are not provided. Priority is defined by the accessible name and description computation algorithm. [[ACCNAME-1.1]]
    • -
  • heading: name comes from the text value of the first descendant (i.e. depth first) element node with the role of heading. Although "heading" may be allowed in addition to "author" in some roles, "heading" is used in content only if higher priority "author" features are not provided. Priority is defined by the accessible name and description computation algorithm. [[ACCNAME-1.1]]
    • +
  • heading: name comes from the text value of the first descendant (i.e., depth first) element node with the role of heading. Although "heading" may be allowed in addition to "author" in some roles, "heading" is used in content only if higher priority "author" features are not provided. Priority is defined by the accessible name and description computation algorithm. [[ACCNAME-1.1]]
  • legend: name comes from the text value of the first descendant element node with the role of legend. Although "legend" may be allowed in addition to "author" in some roles, "legend" is used in content only if higher priority "author" features are not provided. Priority is defined by the accessible name and description computation algorithm. [[ACCNAME-1.1]]
  • prohibited: the element has no name. Authors MUST NOT use the aria-label or aria-labelledby attributes to name the element.
    • From 6fd283661095dac12c82edde9b002cfb07fa5c77 Mon Sep 17 00:00:00 2001 From: James Craig Date: Wed, 25 Jan 2023 14:22:11 -0800 Subject: [PATCH 22/24] m. ed Co-authored-by: Scott O'Hara --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index 8d4b037e8..51055a96a 100644 --- a/index.html +++ b/index.html @@ -6579,7 +6579,7 @@
    Presentational Roles Conflict Resolution

    A perceivable section containing content that is relevant to a specific, author-specified purpose and sufficiently important that users will likely want to be able to navigate to the section easily and to have it listed in a summary of the page. Such a page summary could be generated dynamically by a user agent or assistive technology.

    Authors SHOULD limit use of the region role to sections containing content with a purpose that is not accurately described by one of the other landmark roles, such as main, complementary, or navigation.

    -

    Authors MUST give each element with role region a brief label that describes the purpose of the content in the region. For host languages that support elments with the default role of region (e.g. HTML section), an explict region role must be defined (e.g. role="region") to enable the nameFrom: heading technique.

    +

    Authors MUST give each element with a region role a brief label that describes the purpose of the region. For host languages that support elements with the default role of region (e.g., HTML section), authors would need to specify an explicit role="region" on the element to enable the nameFrom: heading technique.

    Assistive technologies SHOULD enable users to quickly navigate to elements with role region. Mainstream user agents MAY enable users to quickly navigate to elements with role region.

    From c852c8f1b55cf9c9ab55d8954b575a3dc65c397c Mon Sep 17 00:00:00 2001 From: James Craig Date: Wed, 25 Jan 2023 14:29:32 -0800 Subject: [PATCH 23/24] remove namefrom: encapsulation --- index.html | 1 - 1 file changed, 1 deletion(-) diff --git a/index.html b/index.html index 51055a96a..fd297d579 100644 --- a/index.html +++ b/index.html @@ -532,7 +532,6 @@

    Accessible Name Calculation

    1. author: name comes from values provided by the author in explicit markup features such as the aria-label attribute, the aria-labelledby attribute, or the host language labeling mechanism, such as the alt or title attributes in HTML, with HTML title attribute having the lowest precedence for specifying a text alternative.
    2. contents: name comes from the text value of the element node. Although this may be allowed in addition to "author" in some roles, this is used in content only if higher priority "author" features are not provided. Priority is defined by the accessible name and description computation algorithm. [[ACCNAME-1.1]]
      3. -
    3. encapsulation: name comes from the text value of the element node with role label that is the closest ancestor. Although "encapsulation" may be allowed in addition to "author" and "contents" in some roles, "encapsulation" is used only if higher priority "author" features are not provided. Priority is defined by the accessible name and description computation algorithm. [[ACCNAME-1.1]]
    4. heading: name comes from the text value of the first descendant (i.e., depth first) element node with the role of heading. Although "heading" may be allowed in addition to "author" in some roles, "heading" is used in content only if higher priority "author" features are not provided. Priority is defined by the accessible name and description computation algorithm. [[ACCNAME-1.1]]
    5. legend: name comes from the text value of the first descendant element node with the role of legend. Although "legend" may be allowed in addition to "author" in some roles, "legend" is used in content only if higher priority "author" features are not provided. Priority is defined by the accessible name and description computation algorithm. [[ACCNAME-1.1]]
    6. prohibited: the element has no name. Authors MUST NOT use the aria-label or aria-labelledby attributes to name the element.
      7. From 51af51b60ff322932959bdbef65fd5068dedafb5 Mon Sep 17 00:00:00 2001 From: James Craig Date: Wed, 25 Jan 2023 14:52:47 -0800 Subject: [PATCH 24/24] remove namefrom: legend --- index.html | 1 - 1 file changed, 1 deletion(-) diff --git a/index.html b/index.html index fd297d579..84fdb6bf1 100644 --- a/index.html +++ b/index.html @@ -533,7 +533,6 @@

      Accessible Name Calculation

    7. author: name comes from values provided by the author in explicit markup features such as the aria-label attribute, the aria-labelledby attribute, or the host language labeling mechanism, such as the alt or title attributes in HTML, with HTML title attribute having the lowest precedence for specifying a text alternative.
    8. contents: name comes from the text value of the element node. Although this may be allowed in addition to "author" in some roles, this is used in content only if higher priority "author" features are not provided. Priority is defined by the accessible name and description computation algorithm. [[ACCNAME-1.1]]
    9. heading: name comes from the text value of the first descendant (i.e., depth first) element node with the role of heading. Although "heading" may be allowed in addition to "author" in some roles, "heading" is used in content only if higher priority "author" features are not provided. Priority is defined by the accessible name and description computation algorithm. [[ACCNAME-1.1]]
      10. -
    10. legend: name comes from the text value of the first descendant element node with the role of legend. Although "legend" may be allowed in addition to "author" in some roles, "legend" is used in content only if higher priority "author" features are not provided. Priority is defined by the accessible name and description computation algorithm. [[ACCNAME-1.1]]
    11. prohibited: the element has no name. Authors MUST NOT use the aria-label or aria-labelledby attributes to name the element.