AccName algorithm doesn't account for specific roles and how these need to be treated differently when computing name from content

[accdc]

The following code block is an excerpt from the Naming Computation Prototype at https://raw.githubusercontent.com/WhatSock/w3c-alternative-text-computation/8767d9a9250443ca0297acc4646411a13b3f24b1/docs/Sample%20JavaScript%20Recursion%20Algorithm/recursion.js

It reflects a discussion on the ARIA WG list regarding this topic referenced at https://lists.w3.org/Archives/Public/public-aria/2017Jun/0057.html

This has a fundamental impact on the recursion algorithm, but it is not detailed within the spec, and it really should be.

These are rules that dictate when and how name from content should be computed, and for which roles they apply.

    var isException = function(node, refNode) {
        if (!refNode || !node || refNode.nodeType !== 1 || node.nodeType !== 1) {
            return false;
        }

        // Always include name from content when the referenced node matches list1, as well as when child nodes match those within list3
        var list1 = {
            roles: ['link', 'button', 'checkbox', 'option', 'radio', 'switch', 'tab', 'treeitem', 'menuitem', 'menuitemcheckbox', 'menuitemradio', 'cell', 'columnheader', 'rowheader', 'tooltip', 'heading'],
            tags: ['a', 'button', 'summary', 'input', 'h1', 'h2', 'h3', 'h4', 'h5', 'h6', 'menuitem', 'option', 'td', 'th']
        };

        // Never include name from content when current node matches list2
        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'],
            tags: ['article', 'aside', 'body', 'select', 'datalist', 'optgroup', 'dialog', 'figure', 'footer', 'form', 'header', 'hr', 'img', 'textarea', 'input', 'main', 'math', 'menu', 'nav', 'section']
        };

        // 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 matches list1.
        var list3 = {
            roles: ['combobox', 'term', 'definition', 'directory', 'list', 'group', 'note', 'status', 'table', 'rowgroup', 'row', 'contentinfo'],
            tags: ['dl', 'ul', 'ol', 'dd', 'details', 'output', 'table', 'thead', 'tbody', 'tfoot', 'tr']
        };

        var inList = function(node, list) {
            var role = node.getAttribute('role');
            var tag = node.nodeName.toLowerCase();
            return (
                list.roles.indexOf(role) >= 0 ||
                (!role && list2.tags.indexOf(tag) >= 0)
            );
        };

        if (inList(node, list2)) {
            return true;
        } else if (inList(node, list3)) {
            if (node === refNode) {
                return !isFocusable(node);
            } else {
                return !inList(refNode, list1);
            }
        } else {
            return false;
        }
    };

[mcking65]

Assigned to the 1.2 milestone because ...

While this issue is very clear and the desired results are clear, finding a good way to address this within the spec is a significant undertaking. The documentation of the algorithm is already overly complex and we have broad agreement that we need to find a way of making the algorithm more understandable. Attempting to resolve this issue with the current algorithm format could very likely result in greater obfuscation rather than more clarity.

[accdc]

Also as documented at: https://github.com/w3c/accname/issues/3#issuecomment-371910735

I agree that the scope of adding this to the spec isn’t feasible at this time.

However browser implementers are making these decisions right now regardless because they have to, so I strongly encourage leaving this functionality within

the functional AccName Prototype code for this reason so at the least we have a positive example of what is expected in practice. All of the areas where

this is ambiguous are documented within the code so browser implementors can make their decisions using informed comparative analysis.

Otherwise, if omitted, and browser implementers strictly follow only what is implied and do nothing else, when this functionality is documented at a later

date everybody will already be doing something different and have to change everything yet again to accomplish what should already make sense in practice

right now, which leads to more confusion and time and money to fix.

From: Matt King notifications@github.com Sent: Wednesday, March 07, 2018 11:28 PM To: w3c/accname accname@noreply.github.com Cc: Bryan Garaventa bryan.garaventa@whatsock.com; Author author@noreply.github.com Subject: Re: [w3c/accname] AccName algorithm doesn't account for specific roles and how these need to be treated differently when computing name from content (#7)

Assigned to the 1.2 milestone because ...

While this issue is very clear and the desired results are clear, finding a good way to address this within the spec is a significant undertaking. The documentation of the algorithm is already overly complex and we have broad agreement that we need to find a way of making the algorithm more understandable. Attempting to resolve this issue with the current algorithm format could very likely result in greater obfuscation rather than more clarity.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/w3c/accname/issues/7#issuecomment-371403457 , or mute the thread https://github.com/notifications/unsubscribe-auth/ABx1aEKqYcSgtvwWcdG2JA0-x8v7-0f3ks5tcN19gaJpZM4SM43w . https://github.com/notifications/beacon/ABx1aNdN5MgsGD2SzD81WiKhIaiXehoxks5tcN19gaJpZM4SM43w.gif