From @cyns on January 12, 2016 18:34

caption feels like a kind of label. should we map it as one?

Copied from original issue: w3c/aria#142

From @cyns on February 26, 2016 18:24

Copied from original issue: w3c/aria#269

From @cyns on January 12, 2016 18:37

Copied from original issue: w3c/aria#144

From @cyns on May 6, 2016 21:5

The UI that pops up from date and time inputs is not reliably mapped to accessibility APIs in browsers and does not reliably work with screen readers. We need to determine the right way to map the relationship between the launcher (button or edit) and popup UI, so that screen readers can find it.

This applies to
input (type attribute in the Date state)
input (type attribute in the Date and Time state)
input (type attribute in the Local Date and Time state)
input (type attribute in the Month state)
input (type attribute in the Week state)

Where these inputs have popup UI. (time doesn't on Chrome.)

Copied from original issue: w3c/aria#364

From @cyns on January 12, 2016 23:54

Copied from original issue: w3c/aria#199

From @cyns on January 12, 2016 18:36

Currently, <details> has no aria mapping. It's a popup control that acts like a dialog. Maybe that's a good match?

Copied from original issue: w3c/aria#143

From ARIA issue 451 raised by @fstorr.

The element has an incorrect default ARIA role of progressbar which causes some assistive technology (I've tested in VoiceOver on OSX 10.11) to announce the element as a "progress indicator" and the value of the element as a percentage rather than the defined value (for example "80%" instead of "4 out of 5").

The HTML AAM specifies no corresponding ARIA role for meter, but it looks like the separate mappings for meter in MSAA+IA2, UIA, and AX reflect the progressbar role and progress element, which isn't correct.

@asurkov, the definition for ROLE_SYSTEM_PROGRESSBAR is wrong for meter. The meter element has semantics distinct from progressbar. Any suggestions? I note that ATK is using ATK_ROLE_LEVEL_BAR (as recommended in ARIA issue #150), which is certainly closer to the semantic for meter, but IA2 doesn't have a similar role.

@cyns, you raised the question of UIA mapping for meter in ARIA issue #344. What's there looks to be the same as the mapping for the progressbar role. How do you suggest UIA distinguish the meter and progress elements?

@cookiecrook, same question: the AX mappings for meter and progress elements are the same and don't reflect the different semantics. Is there a better role/roledescription for meter?

From @cyns on January 12, 2016 23:21

Copied from original issue: w3c/aria#184

From @cyns on April 25, 2016 21:56

table is covered, but not td and tr

Copied from original issue: w3c/aria#352

From @cyns on March 16, 2016 5:15

<input type=checkbox id=foo>
<label for=foo>Include items from <input type=date value="2016-04-01">?</label>

the accessible name of foo should be something like "Include items from April 1, 2016?"
We need to define how those values stringify for the html date, time, color, and all other form elements that aren't of one of the specified roles
If the embedded control has role textbox, return its value.
◾If the embedded control has role menu button, return the text alternative of the button.
◾If the embedded control has role combobox, return the text alternative of the chosen option.
◾If the embedded control has role range (e.g., a spinbutton or slider):

Copied from original issue: w3c/aria#307

From @cyns on January 12, 2016 23:18

Copied from original issue: w3c/aria#183

From @cyns on January 12, 2016 19:37

Copied from original issue: w3c/aria#160

From @cyns on May 4, 2016 0:13

UIA covered in #160. Other APIs need this too.

Copied from original issue: w3c/aria#360

From @cyns on March 18, 2016 23:29

The output element isn't exactly a status bar. I think a more generic mapping (group?) and a live region is better. I've aleady updated the UIA mapping here, but I don't think this is a good mapping for the other APIs either.

Copied from original issue: w3c/aria#309

From ARIA issue #155

In HTML-AAM, UIA uses localized strings "header" and "footer" for both landmark and non-landmark instances of header and footer, differentiating between the two instances via LandmarkType.

In AX, the non-landmark instances are simply mapped to the AXGroup role with "group" as the localized string. The landmark instances of header and footer use "banner" and "footer" respectively. @cookiecrook, I'm assuming you're comfy with this, or do you want to follow suit and use "header" as the AXRoleDescription for the landmark instance of header?

From @cyns on April 15, 2016 23:4

in 5.1.1, aria-description is used for name calculation, but it is not used in 5.1.2 for description calculation, even if it was not used as the name. Is this intentional? If so, what's the rationale?

Copied from original issue: w3c/aria#334

From @cyns on January 12, 2016 21:48

kbd could be mapped as either

1. a new text attribute
2. a group with localized control type (maybe "user input"?)

Copied from original issue: w3c/aria#170

From @cyns on January 12, 2016 23:44

Copied from original issue: w3c/aria#194

From @cyns on May 6, 2016 20:20

The color picker dialog that pops up from input type=color is not reliably mapped to accessibility APIs in browsers and does not reliably work with screen readers. We need to determine the right way to map the relationship between the launcher (button or edit) and popup UI, so that screen readers can find it.

Copied from original issue: w3c/aria#363

From @cyns on January 12, 2016 23:13

Generally not mapped. If the element must be included per Core-AAM Section 5.1.2, map as Group.

Copied from original issue: w3c/aria#180

From @cyns on January 12, 2016 23:36

open question.
There is a culture text attribute in UIA, but TTS engines aren't using it. They're using heuristics instead to determine language. Not convinced that mapping this is valuable. Would like input...

https://msdn.microsoft.com/en-us/library/windows/desktop/ee872119(v=vs.85).aspx

Copied from original issue: w3c/aria#191

From @cyns on January 12, 2016 18:39

control type: group
localized control type: definition
If the text is rendered in Italics, the text pattern will have italic style

Copied from original issue: w3c/aria#145

From @stevefaulkner on March 1, 2016 16:23

It has been suggested that browser mappings for header = banner and footer=contentinfo should be only be exposed when the header/footer elements are scoped to the body element.

refer to w3c/html-aria#27

Copied from original issue: w3c/aria#277

From @stevefaulkner on April 25, 2016 13:10

as per SVG spec, SVG element is role=group
https://svgwg.org/svg2-draft/struct.html#implicit-aria-semantics

Copied from original issue: w3c/aria#347

From @cyns on January 12, 2016 23:45

Seems like it would populate the description field?

Copied from original issue: w3c/aria#195

From @stevefaulkner on February 20, 2016 8:36

test the following elements (where label not already included in name calc) and update where necessary to reflect implementations.

list of labelable elements in HTML5 includes
button input (if the type attribute is not in the hidden state)keygen meter output progress select textarea

http://www.w3.org/TR/html5/forms.html#category-label

Copied from original issue: w3c/aria#259

From @cyns on May 9, 2016 17:46

This markup
<label>Wait <input type=number value=5> minutes before rebooting</label>
should result in an accessible name of "Wait 5 minutes before rebooting" for the number input. The recursive algorithm in accname-aam will result in that string, but it is not clear reading html-aam that this is covered. Is it the expectation that the accname-aam algorithm will be run for all elements, or only for form elements that contain aria-label, aria-labelledby, or aria-describedby?

Copied from original issue: w3c/aria#369

From @cyns on January 12, 2016 23:40

ControllerFor pointing to target of the list attribute. Refer to input elements mapping.

Copied from original issue: w3c/aria#192

From @richschwer on April 26, 2016 19:58

The form element in HTML should only map to the ARIA form role if it has a label. Otherwise, it maps to the normal form mapping on the platforms. The reason is backward compatibility for old code that does things like embed a single button in form or make form the container for all the content in the page besides

Copied from original issue: w3c/aria#353

From @cyns on February 26, 2016 21:23

Apple maps address as an aria landmark role of content-info. IA2 and ATK map it like a div. I think it was at some point mapped to aria role=content-info, but I can't find when that was changed.

I can see how it is similar to contentinfo, though not a perfect match. I also don't think it's important enough (on most web pages) to be part of the landmark loop, which should cover major chunks of the page.

Copied from original issue: w3c/aria#273

From @cyns on March 31, 2016 19:37

ControlType: Text
LocalizedControlType: "time"
FullDescription: value of datetime attribute

Add the datetime attribute value as the lowest priority for description mapping for the element

Copied from original issue: w3c/aria#314

From @cyns on January 12, 2016 18:33

Canvas has an author-supplied sub-dom, which also maps into the accessibility api tree
The audio and video elements can have a whole tree of children if @controls is present.
Should we add some general language to the document on how to handle these situations?

Here's what we have for UIA for canvas now. It seems inadequate.
Control Type: Image
NOTE: subdom elements will be mapped separately.

Copied from original issue: w3c/aria#141

From @cyns on April 14, 2016 23:50

figure is wrong. Check the others.

Copied from original issue: w3c/aria#330

From @cyns on January 12, 2016 19:50

Edge uses a textbox and a button for its default rendering of <input type=file>. If the element is wrapped by a <label> or referenced by a <label for> which control (or both) should get the name?

Copied from original issue: w3c/aria#163

From @cyns on February 26, 2016 20:2

Control Type: Group
Localized Control Type: address
Landmark Type: Custom
Localized Landmark Type: content information

Copied from original issue: w3c/aria#270

From @cyns on February 2, 2016 18:24

HTML spec on has examples like this

<meter value="0.5">Moderate activity</meter>

Where should the inner phrasing content "Moderate activity" be mapped in the AAPIs? Is this a value? Part of name or description? Something else?

Copied from original issue: w3c/aria#240

From @cyns on April 14, 2016 17:43

I couldn't find an answer in any of the specs as to whether the meter element is expected to be focusable.

Copied from original issue: w3c/aria#327

From @cyns on January 30, 2016 1:45

This example from the HTML5 spec has the datalist providing values for the range control, but having no UI of its own. In this case, it would not be mapped to the aria listbox role. I think it would not be mapped at all, only providing value data to the range which is then mapped as a slider. Are there other examples of where datalist is not a listbox?

<input type="range" min="-100" max="100" value="0" step="10" name="power" list="powers">
<datalist id="powers">
<option value="0">
<option value="-30">
<option value="30">
<option value="++50">
</datalist>

https://www.w3.org/TR/html51/semantics.html#range-state-(type=range)

Copied from original issue: w3c/aria#233

The script that transforms the tables into summary/details is broken.

From @cyns on January 12, 2016 23:42

The relationship between the input and the datalist, via the list reference, is very similar to the aria-controls relationship.

Copied from original issue: w3c/aria#193

From @cyns on April 23, 2016 21:22

should we map meter to the following aria?

role = progressbar
aria-roledescription = meter
aria-readonly = true
aria-valuemax = max attribute
aria-valuemin = min attribute
aria-valuenow = value attribute
aria-valuetext = localized string representing the result of optimal calculation (we use "good", "fair", "poor")

Copied from original issue: w3c/aria#344

From @cyns on March 31, 2016 19:46

Should it be no corresponding aria property?

Copied from original issue: w3c/aria#315

From @cyns on February 26, 2016 1:19

Copied from original issue: w3c/aria#266

From @cyns on January 12, 2016 23:50

For example, display:none removes elements from the accessibility tree.

Copied from original issue: w3c/aria#198

From @cyns on January 12, 2016 23:15

abbr should replace (or maybe add to?) the inner text of the element, and participate in name calculation.

Copied from original issue: w3c/aria#181

From @cyns on January 12, 2016 21:58

feels label-y

Copied from original issue: w3c/aria#173

From @cyns on January 12, 2016 18:43

Seems label-y

Copied from original issue: w3c/aria#149

From @jasonkiss on February 10, 2016 5:36

Settle on single way to indicate/present names and values for various UIA structures, properties, attributes, e.g. control patterns, control type, localized control type, landmark type, localized landmark type, text style attributes.
Currently there is some variance in how these are indicated.

Copied from original issue: w3c/aria#252

From @mcking65 on May 2, 2016 2:6

The html AAM maps the select element differently based on the size and multiple selection values.

This seems like using role to describe presentation rather than interaction model.

HTML select has the interaction model of a listbox regardless of the value of size.

ARIA combo is defined as a composite that includes a textbox and a separate popup element. HTML select does not include a textbox that instantiates a separate popup element.

In the APG, when describing how to build a custom element that is a single-select list, it seems strange that we would tell authors to use combobox when presenting the widget one way and listbox when presenting it another, even if both presentations have the same interaction model.

I propose that HTML select should always map to listbox.

Copied from original issue: w3c/aria#359

From @cyns on January 12, 2016 18:42

Consider adding a "term" role to aria? It doesn't seem like the current mapping provides enough info to AT.

Copied from original issue: w3c/aria#148