monorepo: add graphics-aria history #2189
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Member
pkra
commented
May 21, 2024
•
pkra
commented
- add graphisc-aria history
- remove extraneous files
- adjust links to aria-common
* Updated to use require to load respec pieces A change to ReSpec messaging meant we needed to update the way we pull in the respecEvents hook. ReSpec also stopped exporting some messages, so that was bad. ReSpec has been repaired, and we are now more futureproof. * Fixed a redeclaration of respecEvent.
The ARIA Working Group agreed to move role="text" to ARIA 2.0. See: https://lists.w3.org/Archives/Public/public-aria-admin/2016Apr/0030.html Unfortunately, we have not yet branched for 1.1 so in order to "remove" it for 1.1, I'm commenting it out. That way, it's gone for those reading the spec, and preserved until we're ready to properly move it.
Added to: * checkbox * menuitem * menuitemcheckbox * menuitemradio * option * radio * spinbutton * switch * tab * treeitem
* Add warning about password role * Make password warning note use warning styling * Make whitespace consistent
* Added detection of required states or properties. Now indicates if a state / property is required when inherited. Fixes #386 * Updated to match latest aria 1.1 * Changed saveRole documentation You now need to use #saveRoles instead of ?saveRoles because of some weird change in ReSpec. * Changed my affiliation. Also fixed a typo. * Updated to latest data from ARIA 1.1 * Fixed processing of requireds Now states / props are never duplicated if they are locally required and were also mentioned in a super class.
As mentioned in issue #382, the subrole row of the role tables stopped being populated when I wrapped the roles in section elements.
* Added code to accumulate lists of where names are from. Also added placeholders in the aria spec for them in sections 5.2.7.4 and 5.2.7.5 as per @joanmarie Note that this addresses my action in Tracker 1723 * Made changes to address @joanmarie concerns Note that because of these changes the new script code does not actually populate any indices; they are commented out. * Added handling for required names * Added name to required.
This restoration was requested as part of Action-1723. Given that the text in question seems to have been the victim of over-enthusiastic deletion in commit 82e79c7, in which we removed the text alternative calculation text from the ARIA spec, I'm restoring independent of that action.
This is desired so that a single location may be referenced by other specs, such as the Core AAM. * Initial proposal * Make changes based on feedback from Joseph and others * Address Amelia's comments on intrinsic host language semantics and common conflict section on the presentation role * Remove some restrictions pertaining to native host language semantics * Put Conflict Resolution content in a section * Add exception to Conflicts with Host Language Semantics for permanently presentational roles
Highlights the need for wide review and alerts readers that this role may be removed.
* On branch action2039-autocomplete, modified: aria/aria.html. First draft of revised description of aria-autocomplete to resolve action 2039. Goal is to more clearly explain the purpose of each value. Added normative authoring statements related to how aria-autocomplete can be used in conjunction with aria-activedescendant. * On branch action2039-autocomplete, modified: aria/aria.html. Added text explaining that autocomplete is not a state and which states to use to indicate the presence of a suggestion. reworded the descriptions of the values for autocomplete to make it clear they describe what will happen rather than what is happening. * On branch action2039-autocomplete, modified: aria/aria.html. Editorial revisions to new wording for the description and values of aria-autocomplete. * On branch action2039-autocomplete, modified: aria/aria.html. More editorial revisions to the action 2039 proposal for aria-autocomplete. * On branch action2039-autocomplete, modified: aria/aria.html. In the action 2039 proposal for aria-autocomplete, added authoring requirement for aria-haspopup when list or both is used. * On branch action2039-autocomplete, modified: aria/aria.html. In the action 2039 proposal for aria-autocomplete, added authoring requirement related to aria-expanded. * On branch action2039-autocomplete, modified: aria/aria.html. Made editorial refinements to the action 2039 proposal for aria-autocomplete. * On branch action2039-autocomplete, modified: aria/aria.html. More editorial refinement to action 2039 proposal for the aria-autocomplete description. * On branch action2039-autocomplete, modified: aria/aria.html. In the action 2039 proposal for the description of aria-autocomplete, made final editorial refinements to the proposed text and included an additional clarification of authoring requirements for autocomnplete fields that pre-select a specific suggestion. * On branch action2039-autocomplete, modified: aria/aria.html. Completed revisions of the aria-autocomplete description to address feedback provided in the June 2, 2016 ARIA caucus. * For inline autocomplete, revised language to removed the word "state" when refering to selected text to address concerns that authors may think that aria-selected needs to be applied to text input. * Added author MUST statement requiring aria-controls to be used if aria-autocomplete is set to list or both. * Changed the tense used in the values table from future to present. * Fixed some typos. Made additional improvements to address issues I discovered while completing the above revisions. Issue: if the user provides input for which the application is unable to make a prediction of the user's intent, there will not be any suggestions for how to complete the input. The property definition and value definitions did not effectively communicate this conditional nature of the appearance of predictions. Resolution: * In the first paragraph that provides the property definition, changed "triggers" to "could trigger". * In the value definitions table, incorporated the word "may" to reflect the conditional nature of autocomplete behavior. Issue: the prose for normative conditions was dense, making it difficult to parse out all applicable normative requirements for some situations. Resolution: Simplified the presentation of normative requirements by using ordered lists where multiple requirements apply to the same set of conditions. * On branch action2039-autocomplete, modified: aria/aria.html. Revised paragraph describing the meaning of aria-autocomplete="none" to include a normative authoring statement. Made some addition editorial changes. * On branch action2039-autocomplete, modified: aria/aria.html with minor editorial revisions to the aria-autocomplete description. * On branch action2039-autocomplete, modified: aria/aria.html with additional editorial revisions to the description of aria-autocomplete.
* Taken from email to the public aria list: https://lists.w3.org/Archives/Public/public-aria/2016May/0159.html * Modified to replace non-normative occurrences of "should". by Joseph Scheuhammer <clown@alum.mit.edu>
1. ACTION-2080: Limit the use of role password to elements which are
password-like
Authors:
* Single-line (SHOULD)
* Editable or explicitly marked as read only (MUST)
User Agents:
* Ignore the password role which fails to meet the above requirement
2. ACTION-2079: Draft "host language should" language for password that
they should restrict elements it can apply to
Host languages:
* SHOULD document that the password role can only be used on elements
that are editable and not permanently read only
…entational On at least some platforms, the buttons to increment and decrement the values of the spinbutton are exposed to assistive technologies. This exposure is deliberate and appropriate given that each button can be independently clicked on to change the value. While the spec does state that authors SHOULD ensure this functionality can be accomplished via the keyboard, this does not address devices which lack keyboard input. We do not want to forbid this exposure when authors and/or user agents deem it necessary. Note that the working group plans to add some clarifying language on behavior with respect to spinbutton children.
…be interactive This is largely an editorial clarification with the addition of normative language for authors. It maintains the ARIA 1.0 idea that a separator can be either a horizontal rule or an interactive window splitter, but it adds language that explains how that can be done in a way that will result in appropriate assistive technology behaviors. * Add text explaining the two types of separators: structures and widgets * Separator is now described as a structure if it is not focusable * Add a normative statement explaining that authors MAY make a separator focusable and that if they do, it will be recognized by assistive technologies as an interactive widget * Add normative statement saying authors MAY use aria-expanded to describe the state of a separator * Add normative statement saying authors MAY use aria-valuenow to describe the state of a variable separator widget * Add text describing an example of a variable separator * Add widget as a superclass (consistent with what was implied in ARIA 1.0) * Add statement that aria-expanded is supported only if the separator is is focusable (consistent with ARIA 1.0) * Add aria-valuenow, aria-valuemin, aria-valuemax, and aria-valuetext as supported properties for variable separator widgets (new for ARIA 1.1)
* Rewrite text related to conflicts with shortcuts belong to user agents, assistive technologies, and operating systems * Rewrite text related to shortcut discoverability * Add reference to Authoring Practices Guide's keyboard shortcuts section
…oards We already had a statement regarding Meta corresponding to Command. Not mentioning Option seems to have been an oversight.
The ARIA Working Group agreed to move role="password" to ARIA 2.0. See: https://lists.w3.org/Archives/Public/public-aria-admin/2016Jun/0068.html Unfortunately, we have not yet branched for 1.1 so in order to "remove" it for 1.1, I'm commenting it out. That way, it's gone for those reading the spec, and preserved until we're ready to properly move it.
…e separators * Add implicit values: valuemin (0), valuemax (100), and valuenow (50). * Make valuenow required and add an associated "authors MUST". * Add an "authors SHOULD" regarding valuemin and valuemax. * Remove aria-expanded as a supported property. If a platform needs this state, it can be mapped based on the values in the Core AAM. In addition, there was no statement suggesting that authors SHOULD provide an accessible name in environments when there is more than one focusable slider. That statement has been provided as part of these changes.
* Limit children or owned elements to a textbox and/or two buttons. * Authors must manage focus of descendants. * If the spinbutton has a descendant textbox, it should get focus; otherwise the spinbutton itself should. * The buttons should not be in the tab/focus ring.
* Add statement that user agents MUST NOT expose aria-roledescription if it is empty or consists solely of whitespace * Change the note that contained an implied normative author SHOULD limiting use of the roledescription into a normative author SHOULD * Add a normative assistive technology SHOULD statement explaining that roledescription should change only how the name of the role of an element is expressed and should not change which assistive technology functions are provided for an element * Make miscellaneous editorial and formatting changes
New charter has changed license to Respec default
update editors
Use default license
✅ Deploy Preview for ephemeral-daifuku-0dc7d7 ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
pkra
pushed a commit
to w3c/graphics-aria
that referenced
this pull request
Jul 10, 2024
In order to more easily keep track of the many ARIA specifications and spec changes, we are moving to an ARIA monorepo. We will merge this PR after [this PR to add the spec to ARIA](w3c/aria#2189). This repo will remain open for issue tracking, and the editor's draft will still be published here to maintain editor's draft URLs.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.