From @MichielBijl on March 15, 2016 10:44

A couple—if not all—code example links have title attributes set to almost the exact same as their content; these need to go.

Copied from original issue: w3c/aria#299

Copied from original issue: w3c/aria#349
From @jnurthen on April 25, 2016 17:47

Merge Combo and autocomplete
Rewrite description based on ARIA 1.1 spec definition

When working on this issue, there is some old content that may be useful in the file aria-practices-DeletedSectionsArchive.html.
The relevant sections can be seen here:
https://rawgit.com/w3c/aria-practices/master/aria-practices-DeletedSectionsArchive.html#combobox
And at:
https://rawgit.com/w3c/aria-practices/master/aria-practices-DeletedSectionsArchive.html#autocomplete

From @MichielBijl on January 13, 2016 12:32

The Tab Panel design pattern has been reviewed and is ready for development will be reviewed on February 29th.

Copied from original issue: w3c/aria#204

From @MichielBijl on December 7, 2015 17:19

More information (will type out here): https://gitter.im/w3c/a11ySlackers?at=5638b28edcafd1f0750840d9

Copied from original issue: w3c/aria#115

From @MichielBijl on January 26, 2016 10:16

What is the definition of internationalizable as used in APG: A.1.2 Requirements?

Copied from original issue: w3c/aria#226

http://w3c.github.io/aria/practices/aria-practices.html#Site_Navigator_General

For the name of this section, at least put the word (menu) somewhere in brackets... it is hard to find in the table of contents... no developers are looking for a "site navigator", they are looking for a main menu, mobile menu, mega menu, etc.

This document is supposed to be for "real" web developers, not just accessibility insiders, please give the standard language somewhere so they can find the section.

How about "Site Navigation Menu" or simply "Navigation menu", I think that is sufficiently distinct from the "menu" item which also has a confusing name.

How about this?
Distinguish the "Menu" and "Site Navigator" as two types menus:
-"Application Menu"
-"Navigation Menu"
Both of which are easily understood. Currently both "Menu" and "Site Navigator" are confusing.

Current read me contains some basic info, but nothing much. Is there something we absolutely need to have in there?

From @MichielBijl on January 13, 2016 0:8

As noted by Karl Groves: we should enforce beautify standards and require that all PR's pass the validity checks.

As this only affects the practices, I propose we add a separate README.md in there (as to not litter the main README).

@jnurthen noted that because we need to write stuff that is ARIA 1.1/2.0 it might not validate. Still, validating the code to catch other error should be mandatory.

Copied from original issue: w3c/aria#202

Add a mobile-compatible example of a date picker that employs the form of the ARIA 1.1 combobox pattern that pops up a dialog.

Completing this issue will also complete issue #534.

Development is in the issue34-date-picker-examples branch. Use that branch as the base for pull requests related to this issue.

Preview link for feature branch

Date picker combobox example in feature branch

Related to issue #57.

From @LJWatson on May 25, 2015 12:30

We need to address the problem of design pattern accessibility on touch screen devices. Touch ATs intercept all touch gestures. Only click/blur/focus are handled reliably - and they're not sufficient to support interaction with complex widgets like trees.

We should look to include guidance that surfaces these shortcomings, and indicate which of the design patterns will/won't work on touch devices with ATs enabled.

Copied from original issue: w3c/aria#60

A text box and an associated drop-down list of choices where the choices offered are filtered based on the information typed into the box.

Autocomplete in the APG

From @jnurthen on February 2, 2016 21:34

The non-modal dialog http://w3c.github.io/aria/practices/aria-practices.html#dialog_nonmodal defers to the drag and drop section for how to move the dialog. I'm not sure moving a window is the same as drag and drop so we should really specify something different here.

Copied from original issue: w3c/aria#241

From @MichielBijl on April 12, 2016 23:45

Transfered from W3C Bugzilla.

@jnurthen said:

To be used as the basis of the new accordion

Copied from original issue: w3c/aria#326

This is a duplicate

• Rewrite second sentence of first paragraph
• Clarify "trap" focus; replace with more clear language about tab sequence.
• Remove bullet for enter key from keyboard interaction
• Remove note on pressing the escape key
• Fix editorial consistency issues in sections on keyboard and roles/states/properties.
• Add further guidance about initial focus. Address when content is large and first focusable element would cause top of content to scroll out of view. Possibly include note stating initial focus should go to the least destructive action, e.g., like in confirmation dialogs.

As discussed during telecon.

Also, when working on this, fix up/down arrow key problem described in issue #14.

From @stevefaulkner on February 9, 2016 16:40

The WAI-ARIA Primer https://www.w3.org/TR/wai-aria-primer/ document is stale/dead, not worked on for 6 years, includes incorrect outdated information. But there is no way to know this. yet it is still being referenced by current documents (refer to w3c/wcag#158)

Strongly suggest putting a health warning on the document and pointing to documents that contain current information.

Copied from original issue: w3c/aria#249

http://www.w3.org/TR/wai-aria-practices-1.1/#alertdialog

I tried it like it recommends for this demo http://pauljadam.com/demos/detail-message-dialog.html but it did not work and actually broke VoiceOver OS X usage so I had to do it like normally where you set focus to the first logical button inside the dialog and no role=document or tabindex=0.

So basically my demo is going against the spec but I was trying to follow the spec but it did not work as expected.

Thanks!

From @MichielBijl on March 7, 2016 18:31

In the March 7th APG call we decided to rename the tab panel design pattern. Its current name (tab panel) is weird, considering it refers to just a part of the design pattern.

Suggestions:

• Tabs
• Tabbed interface

Copied from original issue: w3c/aria#286

Maybe link to TR? Purge everything we don't need.

From @StommePoes on December 7, 2015 16:8

The current guidelines for tab panel keyboard interactions have this

• "Up arrow - behaves the same as left arrow in order to support vertical tabs
• Down arrow - behaves the same as right arrow in order to support vertical tabs"

Developers (for example at jQuery UI) seem to have taken this to mean "always make up/down arrows mimic left/right arrows in tab-panels", however what this does is prevent sighted keyboarders from scrolling the page. The only option is moving by an entire page with PageUp/PageDown, which is difficult to read blocks of text with, while seemingly offering little gain.

Can either the spec clarify that up/down arrows should only be hijacked IF these are vertical tabs, or better yet, leave them alone all the time? Whether a tab-panel has horizontal or vertical tabs seems to be a pure visual-design/CSS choice and shouldn't change how the things work, nor should these widgets remove current browser functionality by accident.

Copied from original issue: w3c/aria#113

When ARIA 1.0 and the APG 1.0 were released, xHTML was the intended host language. This is now out of date. Suggest updating the prose to either reference HTML or use the phrase "host language".

From @fstorr on December 14, 2015 22:45

In 4.2.7 Providing Navigable Structure within Web Pages, there are recommendations for multiple <h1> elements in a page, which goes against the warning in the HTML 5.1 Headings And Sections spec.

Copied from original issue: w3c/aria#127

The site navigator is overly complicated... It recommends nesting sub widgets such as a tree (for a leftnav) or a role=menu (top nav) in the main navigation dropdown, with aria-owns.
http://w3c.github.io/aria/practices/aria-practices.html#Site_Navigator_General

"Navigation container widget: the navigation items need to be contained in an appropriate widget, such as a tree, menubar, toolbar, or listbox. "

Here are my concerns:

• I'm nervous about this level of complexity. It requires a lot of Assistive technology computing power ... especially aria-owns.
• The WAI ARIA Authoring Best Practices 1.0 Site Navigator, did not receive high uptake... neither did the 1.0 ARIA tree widget and 1.0 menu items outside of academic discussion and experimentation, in the 6 years they have existed. The navigator requires considerable learning for developers and a lot of expertise from a screen reader user who is inevitably going to become confused...
• Consider simplifying the requirements. Consider straight forward lists (and sublists) of links wrapped in a <nav> with aria-expanded. Let's not drown the menu in roles that override the <ul><li> semantics, which have been an understood convention for groups of links for 20 years and which natively gives hierarchy, eliminating the need for aria-owns, which saves AT computing power. Consider a realistic construct that is achievable and which can gain community momentum, consensus and uptake ...

Note regarding keyboard interaction: I think trapping the right/left arrow keys for navigation inside the widget is probably the way to go, but we need to understand that some users will become confused for the next few years. Radio buttons have been around for 20 years and still 20% of screen reader users don't know that they should use the arrow keys once they tab into a radio group. I doubt aria widgets will be much different. I wish I had a solution for that... I don't, but I'm afraid we're headed for the same type of problems if we get too many sub widgets inside <nav> elements.

From @jnurthen on April 11, 2016 18:1

Copied from original issue: w3c/aria#323

Would it be doable to add an AT+Browser support matrix to the design patterns? The obvious challenge is to keep them up to date. I see this as an enhancement for now (let's finish the damn things first).

Relevant tweet: https://twitter.com/sundress/status/726444839819059201

The APG should point to this new repo.

From @pkra on March 9, 2016 10:1

Over on a11ySlackers I stumbled upon http://w3c.github.io/aria/practices/aria-practices.html#math again which always leaves me somewhat confused. Since I'm only a beginner, I was hesitant to post a confused question but @MichielBijl encouraged me to do so, so here I go.

Specifically, I don't understand the example 43 in the Practices WD.

Shortened version:

<div role="math" aria-label="a times x squared plus b times x plus c equals 0">
  <math xmlns='http://www.w3.org/1998/Math/MathML'>
  <!-- snip -->
  </math>
</div>

Since I'm only a beginner, I was wondering what the expected result of this is.

At first I thought this should lead to double-rendering by MathML-capable AT (first the label, then the MathML). However, most ATs I tested simply ignore anything with role=math so the label will not be read (or anything else). If I drop role=math, then NVDA(+MathPlayer) will voice both the label and the MahtML in Firefox.

Then I thought the label would override the remaining content (e.g., that's what Chrome's a11y dev tool extension indicates), but that would mean that AT with MathML support is forced to use the lower-quality option. So I'm probably wrong about that, too.

To give some context, I don't care too much about the MathML, actually. The real problem I see is to make HTML renderings of mathematics accessible and neither the Practices nor the math role description help much with this.

For as simple an example as the one in the Practices, "deep" labels provide quite decent accessibility, e.g.,

 <math>
    <mrow>
      <mrow>
         <mrow>
            <mi>a</mi>
            <mo aria-label="times">&#x2062; <!-- invisible times --></mo>
            <msup aria-label="x squared">
              <mi aria-hidden="true">x</mi>
              <mn aria-hidden="true">2</mn>
            </msup>
         </mrow>
         <mo>+</mo>
         <mrow>
            <mi>b</mi>
            <mo aria-label="times">&#x2062; <!-- invisible times --></mo>
            <mi>x</mi>
         </mrow>
         <mo>+</mo>
         <mi>c</mi>
      </mrow>
      <mo>=</mo>
      <mn>0</mn>
    </mrow>
  </math>

would seem to make more sense to me. But due to the absence of MathML support almost everywhere in the a11y stack, this doesn't actually work. (I would point out that the label actually enhances the original MathML as superscripts carry no semantic meaning in Presentation MathML either.)

However, if one follows the suggestion to use a polyfill MathML-to-HTML5 converter, then there's actually a good chance this could become more accessible than a fixed label. Cf. http://codepen.io/pkra/pen/zqrwQx: the third example renders nicely on NVDA, even allowing some level of exploration. Just to be clear, this only works well for relatively "flat" equations like this one but that likely covers a worthwhile amount of content, especially inline equations.

And one last, related question regarding the "generic HTML" example in the Practices WD. Why can we not expect AT to render this as well as it would render the MathML counterpart, once we add a role=math to it?

<span role="math"><i>a</i><i>x</i><sup>2</sup> + <i>b</i><i>x</i> + <i>c</i> = 0</span>

There's not really a semantic difference between msup/msub and sup/sub, albeit a difficulty of parsing of sup/sub; but that is something Practices can actually help with by recommending wrapping, e.g.,

<span role="math"><i>a</i><span><i>x</i><sup>2</sup></span> + <i>b</i><i>x</i> + <i>c</i> = 0</span>

Not that this works today, but I'm wondering why it shouldn't be. (But I realize this leads to the larger problem of role=math and the lack of ARIA roles for mathematics so I better stop here.)

Copied from original issue: w3c/aria#290

From @michael-n-cooper on August 6, 2015 14:7

Filed at https://lists.w3.org/Archives/Public/public-pfwg-comments/2015JulSep/0002.html by David Power [email protected]

Hi

I've just briefly looked through your authoring practices pages, and I'm
struggling to find any support for my following issue:

As a Visually Impaired Person, it can be difficult to find out quickly how
to use a particular page as there can be several forms, or different types
of content.

Is there something equivalent to a role definition for "abstract" where the
page authors could put something like the following text to explain to a
Visually Impaired Person how to use the web page where they are relying on
screen reader technology which includes functionality to jump to page
content based on html tags/aria roles? For example:

            "This page is the second step in the ordering process where

you can select the book(s) you would like to read. The description of each
book starts with a level 2 header. The description includes: the title,
author, price, a brief synopsis, and available formats. If you want to
order the book, click on the link associated with the book title. If you do
not find the book you are after, please go back to the previous search
page."

My issue is that this type of content is not required for people with normal
vision as they can appropriate the entire page content rather than
navigating an HTML element level.

Regards

Dave Power

Copied from original issue: w3c/aria#78

From @stevefaulkner on May 25, 2015 13:31

expand/collapse or disclosure pattern is common on the web (HTML native UI is details/summary), but there is no design pattern. Suggest adding one
a few examples:
http://thepaciellogroup.github.io/disclosure-button/
http://codepen.io/stevef/pen/jiCBE
http://webcloud.se/jQuery-Collapse/

Copied from original issue: w3c/aria#61

From @karlgroves on September 8, 2015 9:38

This repository's README document discloses contribution guidelines for the ARIA spec. The wiki has a table of Aria Authoring Practices and their status. Neither documents discuss details on requirements for submitting examples. Documenting the requirements (if any) will probably help in getting examples and ensure their quality.

Copied from original issue: w3c/aria#88

• Reviewed
• Edits done
• Code example

A dialog with the primary purpose of communicating a message and acquiring a user response to that message.

Alert Dialog or Message Dialog in the APG

From @MichielBijl on October 12, 2015 18:12

We need to decide on a couple of rules for our code examples. From today's meeting:

• indentation should be four spaces;
• use semi-colons;
• use all caps for constants.

Copied from original issue: w3c/aria#95

From @MichielBijl on January 4, 2016 17:32

It might be helpful to have a design pattern for bread crumbs.

As discussed on a11ySlackers.

Copied from original issue: w3c/aria#130

What do people think of turning the whole thing into a dev docs sort of website?

Relevant Twitter threads:

https://twitter.com/sundress/status/726811296197316608
https://twitter.com/estellevw/status/727211584888557568

Should be the case for most anyway, but needs to be checked to make sure.

Marquee implicit live value does not reflect the spec at http://w3c.github.io/aria/aria/aria.html#marquee

There are no roles specific to carousel. There are many valid ways of constructing them. This pattern will somehow need to provide a lot of latitude in the roles, states, and properties. We might want to even defer to examples for that aspect and explain how the roles/states/properties used provide accessibility.

Use the issue43-add-carousel-pattern branch for all pull requests related to this issue.

Preview current work in carousel pattern branch

Carousel design pattern in issue43-add-carousel-pattern branch

From @detlevhfischer on November 4, 2015 16:5

Using role=menubar for navigation sections leads to badly accessible or inaccessible navigation menus in several combinations of browser / screenreader (in a recent test, problems occured in JAWS / IE, NVDA/FF, iOS/VoiceOver.
Authors should be strongly advised to use menubar / menu consatructs ONLY for application-type content mimicking desktop menus. We havehad cases where developers followed ARIA best practice in good faith and made their navigation inaccessible for SR users as a consequence.

Copied from original issue: w3c/aria#102

From @becka11y on January 18, 2016 22:38

Currently a tab panel activates when the associated tab gets focus. This is not efficient for keyboard users as they must (potentially) wait for the panel content to load before moving focus to the next tab/tab panel. Many designers would prefer to have the user activate the tab to make the tab panel load and display. This is an easy addition to the current behavior. Just remove the phrase that indicate that the tab is activated on focus. It basically makes the tab panel behave more like an accordion.
I have made the changes in the attached pdf. I also quickly modified the existing example from the Open Ajax Alliance to demonstrate this behavior.
ARIA_TabPanelAccordion.html.zip

ARIA_TabPanelAlternative.pdf

Copied from original issue: w3c/aria#206

In 4.2.6 author defined shortcuts the reference to the access module being developed by the xHTML2 WG should be removed. It has no implementations AFAIK.

When working on this issue, there is some old content that may be useful in the file aria-practices-DeletedSectionsArchive.html.
The relevant section can be seen here:
https://rawgit.com/w3c/aria-practices/master/aria-practices-DeletedSectionsArchive.html#accordion

An accordion component is a collection of expandable panels associated with a common outer container.

From @jnurthen on March 11, 2016 18:27

The Media Player section is empty

Copied from original issue: w3c/aria#293