| Summary: | [HTML][assist] Add ARIA to content assist attribute proposals | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Carolyn MacLeod <Carolyn_MacLeod> | ||||
| Component: | JS Tools | Assignee: | Carolyn MacLeod <Carolyn_MacLeod> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | curtis.windatt.public, emoffatt, Michael_Rennie, Silenio_Quarti | ||||
| Version: | 8.0 | ||||||
| Target Milestone: | 11.0 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows 7 | ||||||
| See Also: |
https://git.eclipse.org/r/62219 https://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=62031f22c1cba6fc0012ad4ad8f2e92a0d20ce53 |
||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Carolyn MacLeod
I went through the ARIA information in the w3 HTML spec, but a much better place to get the information we need for content assist is in this table in the "HTML-ARIA" spec: http://w3c.github.io/html-aria/#docconformance and in the follow-on table in the same spec: http://w3c.github.io/html-aria/#allowed-aria-roles-states-and-properties The first table lists the allowed (and not allowed) roles for each html element, and the 2nd table lists the aria states and properties for the "global aria-* attributes" and "any aria-* attributes applicable to the allowed roles" mentioned in the first table. There are 16 global aria attributes that can be used for most html elements. Also, up to about 6 additional aria states and properties can be used, depending on the chosen role. So there could be as many as 22 aria-* attributes added to a content assist list after the role is specified. The role-specific attributes should appear in the content assist list after the role is specified. However, we need to decide how best to handle the 16 global aria attributes that can be added to most html elements at any time. Because they start with "a" they would take up quite a bit of the initial content assist list. We could: 1) Add them to the bottom of the list 2) Add them to the list if the user types "aria" or maybe just "ar" 3) Both (1) and (2). Thoughts? Created attachment 256295 [details]
aria-content-assist.png
I see that we sort-of have an "aria" attribute already in our content assist list.
I've attached a screen snapshot. If the user selects "aria" then they get aria="" inserted (this is not an attribute... just a prefix). They would need to then type the rest of the attribute. Just curious - where did the tooltip text come from? It's a bit misleading, with the Ajax comment in there...
Better still, our content assist has categories - currently, all of the on* events are categorized - and the categories are sorted to the bottom of the list. That's the best place for the aria attributes (including role). The category name should be "ARIA Attributes" to match the title case used for the event attributes. The new category and attributes would be added to attributes.js. Please add a comment explaining how you generated the content (or if it was done manually). We usually reference the MDN page in the url property. You will also have to update htmlContentAssist.js to include your new category and check the category ordering. New Gerrit change created: https://git.eclipse.org/r/62219 Gerrit change https://git.eclipse.org/r/62219 was merged to [master]. Commit: http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=62031f22c1cba6fc0012ad4ad8f2e92a0d20ce53 Closing fixed. |