AccName 1.2 Logic Tree Outline Draft Doc for Refactoring

Hi,

This is sort of important, so I'll need all implementors of AccName to review the attached document at your earliest convenience.



I'll try to be brief, since I've been working on this all day and my brain is a bit fried at the moment.



During the FTF meeting we had last week, I was asked to write the spec text for the CSS content addition to AccName 1.2, and when I started doing this, I encountered some issues that I wasn't able to address with verbiage alone. E.G describing what is needed and inserting it within the spec where CSS content is referred to won't actually make this work, because the order of recursion is still unclear and will not result in the same results across platforms if implemented as written.



So, one thing we spoke of last week also, was totally refactoring AccName to achieve two goals if possible, (1) to make it simpler, and (2) to make it easier to understand.



With this in mind, I've created an outline that breaks down all of the steps required to make the algorithm work programmatically within a recursive algorithm, and the syntax should be familiar to any programmer who has experience with object oriented languages.



Basically, AccName is complicated because it's not always clear what or when something is supposed to happen, and representing this is a single linear process from beginning to end forces implementors to have to break all of these processes down themselves into recursive functions that no longer match what the spec says, which is one of the places where it seems we have a lot of discrepancies cropping up.



However, if you break AccName down into a series of simple data flow processes, including the order in which these processes need to run, then it becomes clear that the AccName computation is mainly driven on basic common sense protocols. This is what I've attached as a draft.



The draft logic tree includes all of the familiar aspects that we already have within 1.1 as we've spoken of in the past, plus many of the 1.2 additions that we have agreed should go into 1.2, and these are implemented where they would need to exist programmatically in order to work within browsers so we can all get the same results if implemented the same way within the browsers. This also includes the CSS content we spoke of during the meeting last week as well.



Since this is a draft outline only, I'm not trying to make this into spec text, or to define all words in their entirety, which I would end up doing later as part of the 1.2 spec if we can agree that a particular flow is desired to make this more understandable for implementors. Visual styling might help too, though I'll need help from others to identify what makes sense if this is worth  pursuing. Also, since Melanie has graciously volunteered to make a visual flow-chart of AccName 1.2 (because she's AWESOME), the outline may help greatly with this once we iron out all the wrinkles going forward.



So, this is what I need from you:



1. Does this even make sense? (If reading it is so confusing that it makes no sense, this experiment didn't work and I'll need to scrap it.)



2. If the data flow does make sense, is anything incorrect or missing from your understanding of the spec?



3. Would it be clearer if phrased differently or if missing information were added, and what info would you recommend if so?



If this is worth continuing, I would likely need to put this on the AccName wiki so others can help with this going forward, but first hopefully I can get some general feedback in the meantime about the clarity of the processes.



My hope is that we can all reach agreement about the data flow process, how this is represented, and add the things we plan to for future ARIA updates by simply plugging these into the outline where we would expect them to appear as part of the algorithm. After which, it should then be much easier to rewrite AccName 1.2 to conform to our expectations, rather than writing the spec first without knowing what we collectively expect to begin with.



In case there are issues with attachments, I'll paste it below as well, though it might mess with the spacing.



Thanks,

Bryan





AccName 1.2 Logic Tree Outline

Key Terms

Explicitly Hidden: Any element that is specifically hidden using the HTML hidden attribute, CSS display:none or visibility:hidden, or if it includes aria-hidden="true".

Implicitly Hidden: Any element contained within a parent element that is explicitly hidden.

Presentational: Any element containing role="presentation" or role="none" that is not focusable and does not include any global ARIA attributes.

Native Markup: Any element that includes a native host-defined mechanism for labelling, such as form fields with label elements, images with alt attributes, and svg elements with embedded desc and title elements.

Name From Content: Any element with an ARIA role mapping that supports 'name from content' as part of its role definition within the ARIA specification.

Exceptions Rule Checklist: A checklist that determines when to process name from contents as part of the recursion algorithm, which is necessary to differentiate names computed on focusable roles, as opposed to parsing name from contents of the same roles when embedded within different roles. To understand the background of this, please read the discussion thread:   https://lists.w3.org/Archives/Public/public-aria/2017Jun/0057.html

    // Always include name from content when the referenced node matches list1, as well as when child nodes match those within list3
    // Note: gridcell was added to list1 to account for focusable gridcells that match the ARIA 1.0 paradigm for interactive grids.
    // So too was row to match 'name from author' and 'name from content' in accordance with the spec.
var list1 = {
roles: ["button", "checkbox", "link", "option", "radio", "switch", "tab", "treeitem", "menuitem", "menuitemcheckbox", "menuitemradio", "row", "cell", "gridcell", "columnheader", "rowheader", "tooltip", "heading"],
tags: ["a", "button", "summary", "input", "h1", "h2", "h3", "h4", "h5", "h6", "menuitem", "option", "tr", "td", "th"]
};

    // Never include name from content when current node matches list2
    // The rowgroup role was added to prevent 'name from content' in accordance with relevant ARIA 1.1 spec changes.
    // The fieldset element and group role was added to account for implicit mappings where name from content is not supported.
var list2 = {
roles: ["application", "alert", "log", "marquee", "timer", "alertdialog", "dialog", "banner", "complementary", "form", "main", "navigation", "region", "search", "article", "document", "feed", "figure", "img", "math", "toolbar", "menu", "menubar", "grid", "listbox", "radiogroup", "textbox", "searchbox", "spinbutton", "scrollbar", "slider", "tablist", "tabpanel", "tree", "treegrid", "separator", "rowgroup", "group"],
tags: ["article", "aside", "body", "select", "datalist", "optgroup", "dialog", "figure", "footer", "form", "header", "hr", "img", "textarea", "input", "main", "math", "menu", "nav", "section", "thead", "tbody", "tfoot", "fieldset"]
};

    // As an override of list2, conditionally include name from content if current node is focusable, or if the current node matches list3 while the referenced parent node (root node) matches list1.
var list3 = {
roles: ["term", "definition", "directory", "list", "note", "status", "table", "contentinfo"],
tags: ["dl", "ul", "ol", "dd", "details", "output", "table"]
};

    // Subsequent roles added as part of the Role Parity project for ARIA 1.2.
    // Tracks roles that don't specifically belong within the prior process lists, but shouldn't have any impact on name from content processing.
    // More need to be added ...
var list4 = {
roles: ["legend"],
tags: ["legend"]
};

AccName 1.2 Logic Tree

Step 1: Process Root Node: Initialize P as {name: "", description: ""}

    A. Set the root node and the current node to the same node to begin processing.
        Continue.

    B. Set the values of P.name and P.description to the returned values of step 2 (Process Current Node) for the current node.
        Continue.

    C. Convert all whitespace characters in the values for P.name and P.description to single spaces and flatten each string into single lines.
        Continue.

    D. If (the values for P.name and P.description are not blank, and both contain the same textual content),
        then set P.description to "".
            Continue.

    E. Trim any leading or trailing whitespace characters from the values for P.name and P.description,
    then return the name and description values as computed for P.
        (Stop)

Step 2: Process Current Node: Initialize Q as {name: "", description: ""}

    A. If (the root node and the current node are not the same node, and the current node is not directly referenced by aria-labelledby or aria-describedby, and the current node is explicitly hidden),
    or if (the root node and the current node are not the same node, and the current node is directly referenced by aria-labelledby or aria-describedby, and the current node is implicitly hidden),
    or if (the current node has already been traversed while computing the name or description for the root node),
        then abort and skip to step 2.J. Otherwise, continue.

    B. If (the current node includes an attached CSS :before pseudo element),
        then set the value of Q.name to the pseudo element content,
        plus a space character if (the pseudo element is styled as a block level element).
            Continue.

    C. Append the values of Q.name and Q.description with the returned values of step 3 (Process Filter Criteria) for the current node.
        Continue.

    D. if (the value of Q.name is blank, and the current node's role supports name from content, and the current node's role is allowed in the exception rule checklist),
        then process each successive first level child node using step 2 (Process Current Node) for the current node, and append the returned name string to the value of Q.name.
            Continue.

    E. If (the current node natively supports embedded child nodes, and the current node includes aria-owns),
        then process each successive id reference and perform step 2 (Process Current Node) on each to get its name, separate each id referenced instance of name with a space character, and combine all into one name string in the order they were processed and append this to the value of Q.name with a space character between them.
            Continue.

    F. If (the current node includes an attached CSS :after pseudo element),
        then append the CSS pseudo element content to the value of Q.name,
        preceded with a space character if (the pseudo element is styled as a block level element).
            Continue.

    G. If (the root node and the current node are the same node, and the value of Q.name is empty, and the current node includes a non-empty title),
        then set the value of Q.name to the title.
            Continue.

    H. If (the root node and the current node are the same node, and the value of Q.name is not empty, and the value of Q.description is empty, and the current node includes a non-empty title),
        then set the value of Q.description to the title.
            Continue.

    I. If (the value of Q.name is not empty, and the current node is visually styled as a block level element or separated on a new line),
    or if (the current node is a control or widget with a value),
        then add a space character to the beginning and end of Q.name.
            Continue.

    J. Return the name and description values as computed for Q.
        (Stop)

Step 3: Process Filter Criteria: Initialize R as {name: "", description: ""}

    A. If (the root node and the current node are the same node, and the current node includes aria-describedby),
        then process each successive id reference and perform step 2 (Process Current Node) on each to get its description, separate each id referenced instance of description with a space character, and combine all into one description string in the order they were processed and set this as the value of R.description.
            Continue.

    B. If (the current node includes aria-labelledby, and the current node is not already part of an aria-labelledby traversal),
        then process each successive id reference and perform step 2 (Process Current Node) on each to get its name, separate each id referenced instance of name with a space character, and combine all into one name string in the order they were processed and set this as the value of R.name.
            If (R.name is not empty), then abort and skip to step 3.G. Otherwise, continue.

    C. If (the current node includes a non-empty value for aria-label, and the current node is not an embedded control or widget),
        then set the value of R.name to the value of aria-label.
            If (R.name is not empty), then abort and skip to step 3.G. Otherwise, continue.

    D. If (the current node is not an embedded control or widget, and the current node's native markup provides a supported host-defined labelling mechanism, and the current node is not presentational),
        then set the value of R.name as the host-defined label content.
            If (R.name is not empty), then abort and skip to step 3.G. Otherwise, continue.

    E. If (the root node and the current node are not the same node, and the current node is an embedded control or widget),
        then set the value of R.name as the current widget value, or to "" if no value is defined.
            If (the current node is an embedded control or widget as specified), then abort and skip to step 3.G. Otherwise, continue.

    F. If (the current node is a standard text node),
        then set the value of R.name to the textual content of the node.
            If (the current node is a standard text node as specified), then abort and skip to step 3.G. Otherwise, continue.

    G. Return the name and description values as computed for R.
        (Stop)






Bryan Garaventa

Principal Accessibility Architect

Level Access, Inc.

Bryan.Garaventa@LevelAccess.com

415.624.2709 (o)

www.LevelAccess.com