Accessibility support

[dclaux]

Release	Renderer status	Tasks status
Backlog	🔄 .NET (#2473) 🔄 Android (#2474) 🔄 iOS (#2475) 🔄 TS (#1695) 🔄 UWP (#2476)	✔️ Shared (#2472)

Solves requests

• Better accessibility support (Request: Better accessibility support #2024)

Narration, keyboard navigation

Also need to consider

• Use of proper HTML tags and attributes (e.g anchor element for hyperlinks, alt on image etc)
• Support for ARIA attributes
• Support for high contrast mode
• Support for supplying high contrast images
• backgroundColor on Image elements (letting authors supply high contrast colors)
• Action.title should be a tooltip for selectActions where appropriate
• Elements/Input and need an "ariaLabel" attribute that gets passed along to each renderer

Related details:

• Tooltips on clipped TextBlock's (Automatic tooltip for TextBlock's that get clipped #1788)
• Hi-contrast remote images (High contrast and theme support for images and img background colors #1648)

Also, Cortana ran into the following two issues on 7/5/2018 that need to be fixed...

Narrator is not narrating the state as "Collapsed/Expand" when user trigger on 'Set due date' button.
Solution: This needs aria-expanded property set on the showcard action in adaptive card.

Name property should be more descriptive for ‘calendar date’ edit box.
When screen reader focus land on 'calendar date' here narrator should narrate as 'Set due date dd/mm/yyyy'

JS issues	Description
#2235	Name/ Alt-text property is not proprly defined for Images.
#2236	Focus is landing on non-interactive elements after activating the 'Show a simple' Adaptive cards button.
#2237	Name property does not defined for “Date" and "Time" editable text boxes from all card inputs data
#2238	Label is not properly associated with controls defined under 'What color do you want'.
#2239	Reading 'Group' between the text boxes while navigating in scan mode
#2240	Incorrect role is define for 'View details' control.
#2241	Meaningful sequence is not correct at 'Depart and Arrive' text content while navigating in scan mode.
#2242	'SurfacePro4 and Surface Pro 4 (2)' controls define as a button but visually looks like an Image on 'Receipt card' content

Auto-generated task status

• Shared
• .NET
• Android
• iOS
• TS
• UWP

[matthidinger]

(comments merged into top of issue)

[dclaux]

High contrast is addressed via HostConfig, I don't think we need anything else in that area.

[yeohan]

Here are three particular requests for iOS. This comes with these new properties in JSON - accessibility_label, accessibility_hint, and accessibility_role (could be renamed for better cross-platform support).

TextBlock as a Link

{
    "type": "TextBlock",
    "color": "accent",
    "size": "default",
    "maxLines": 99,
    "text": "+81 3 4535 3926",
    "horizontalAlignment": "left",
    "spacing": "none",
    "accessibility_label": "Phone number link +81 3 1234 5678",
    "accessibility_hint": "Double tap to make a phone call",
    "accessibility_role": "link"
}

VoiceOver should read this out, starting with the label (instead of the text), role, and the description. Say, "Phone number link +81 3 1234 5678", "link", "Double tap to make a phone call".

In this case, iOS UILabel should have these properties accordingly - accessibilityLabel, accessibilityHints, accessibilityTraits.

TextBlock as a Button

{
"type": "TextBlock",
"horizontalAlignment": "center",
"text": "Add contact",
"maxLines": 1,
"weight": "default",
"size": "default",
"spacing": "small",
"accessibility_hint": "Double tap to add a contact",
"accessibility_role": "button"
}

VoiceOver should read this out, starting with the text, role, and the description. Say, "Add contact", "button", "Double tap to add a contact".

In this case, iOS UILabel should have these properties accordingly - accessibilityHints, accessibilityTraits.

Inaccessible TextBlock (TextBlock as layout element)

{
"type": "TextBlock",
"horizontalAlignment": "center",
"text": "-",
"maxLines": 1,
"weight": "default",
"size": "default",
"spacing": "small",
"accessibility_enabled": false
}

VoiceOver should NOT read this element (ignore and skip moving focus onto it).

In this case, iOS UILabel should have these properties accordingly - isAccessibilityElement.

[andrewleader]

Proposal too vague, need more specific details on what we're going to solve vs what's not supported today, and how big of an issue those things actually are before deciding whether we should do them