Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 475505

Summary: [HTML][assist] Add ARIA to content assist attribute proposals
Product: [ECD] Orion Reporter: Carolyn MacLeod <Carolyn_MacLeod>
Component: JS ToolsAssignee: 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 Flags
aria-content-assist.png none

Description Carolyn MacLeod CLA 2015-08-20 11:34:46 EDT
Need to add content assist for ARIA attributes (roles, states, and properties).
I will add lists to this bug as I scrape them out of the spec.
Comment 1 Carolyn MacLeod CLA 2015-09-01 10:53:21 EDT
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?
Comment 2 Carolyn MacLeod CLA 2015-09-01 11:00:06 EDT
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...
Comment 3 Carolyn MacLeod CLA 2015-09-01 12:20:56 EDT
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.
Comment 4 Curtis Windatt CLA 2015-09-03 13:47:55 EDT
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.
Comment 5 Eclipse Genie CLA 2015-12-08 09:33:19 EST
New Gerrit change created: https://git.eclipse.org/r/62219
Comment 7 Michael Rennie CLA 2015-12-14 11:00:05 EST
Closing fixed.