w3c / aria-practices Goto Github PK
View Code? Open in Web Editor NEWWAI-ARIA Authoring Practices Guide (APG)
Home Page: https://www.w3.org/wai/aria/apg/
License: Other
WAI-ARIA Authoring Practices Guide (APG)
Home Page: https://www.w3.org/wai/aria/apg/
License: Other
This is a duplicate
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 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:
Copied from original issue: w3c/aria#286
From @jnurthen on March 11, 2016 18:27
The Media Player section is empty
Copied from original issue: w3c/aria#293
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
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
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">⁢ <!-- 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">⁢ <!-- 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
Should be the case for most anyway, but needs to be checked to make sure.
Current read me contains some basic info, but nothing much. Is there something we absolutely need to have in there?
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
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.
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
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
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.
As discussed during telecon.
Also, when working on this, fix up/down arrow key problem described in issue #14.
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
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
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 October 12, 2015 18:12
We need to decide on a couple of rules for our code examples. From today's meeting:
Copied from original issue: w3c/aria#95
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 @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
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 @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 @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
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 January 4, 2016 17:32
It might be helpful to have a design pattern for bread crumbs.
Copied from original issue: w3c/aria#130
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
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.
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.
Carousel design pattern in issue43-add-carousel-pattern branch
From @StommePoes on December 7, 2015 16:8
The current guidelines for tab panel keyboard interactions have this
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
The APG should point to this new repo.
Marquee implicit live value does not reflect the spec at http://w3c.github.io/aria/aria/aria.html#marquee
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".
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:
<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
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.
Date picker combobox example in feature branch
Related to issue #57.
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
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
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
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
Copied from original issue: w3c/aria#206
A dialog with the primary purpose of communicating a message and acquiring a user response to that message.
Maybe link to TR? Purge everything we don't need.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.