-
Notifications
You must be signed in to change notification settings - Fork 121
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
initial draft for role="generic" issue #699 #805
Conversation
Preview of new role sections: |
New preview of single generic role: |
Preview of new aria-textseparation attribute:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I attempted to write some authoring guidance based on what we have in this PR, and I could not do it. I think we have too many open questions to move forward with this. I added some comments to the PR to help clarify some of the problems. I'll add other questions in the issue.
@carmacleod any chance we can split text separation into a separate PR? |
3190232
to
5824d3a
Compare
Done. Also refreshed branch. This PR now only contains Note that I added "Name from: prohibited" to the |
7497c9f
to
a7390ef
Compare
Discussion points: @scottaohara @a11ydoer
I see that to create an autonomous custom element, you extend HTMLElement: ... and to create a customized built-in element (and automatically get all of the semantic and behavioral goodness that comes with a pre-existing element), you extend that element (e.g., button): Here's the list of elements that will (probably) be mapped to generic:
So I'm thinking that maybe (?) someone might extend any one of those, in which case it would be a "customized built-in element" with no semantics (is that correct?). Anyhow, what do you think about modifying the above sentence to something like:
@mcking65
How about adding an extra sentence, something like:
Should we mention |
regarding an autonomous custom element, e.g. If extending an existing HTML element e.g. Unless I'm absolutely missing something here, I honestly don't know why an author would ever use Per our meeting last week, I do see the benefit of having the role in general, to allow mappings for elements that would otherwise have no mapping, but need to expose something to the accessibility API. But as far as authors actually using it, I'd be happier with just a direct "you shouldn't need this." re:
per your "currently" comment, any reason as to why this would change? |
- add note saying authors should not use in content - add editor's note about global properties triage
e78b884
to
25fec15
Compare
Per discussion with @scottaohara, the "Note" can be simplified to:
Discussion points:
@joanmarie, do you know why dfn is listed under "Triage needed" in the Generic Role section of the Role Parity wiki page? (i.e. will |
@carmacleod Because I hadn't updated the wiki. |
Conclusion re point 1: Move out of the note and SHOULD NOT. Conclusion re point 2: Not an author error. Conclusion re point 3: Authoring guidance. |
To be landed Tuesday afternoon assuming no more objections! |
@carmacleod @jnurthen @mcking65 @joanmarie Was the name for |
@jongund asked:
Yes, for the reason that it is a word frequently used throughout the spec and defined in the glossary. We know from the experience of naming a role "application," that using words like that is riddled with problems. |
issue #699.
Notes & Questions for
block
andinline
generic roles draft:roletype
for both (should it bestructure
?)HTML div/span
(should we also listCSS display:block/display:inline
? or maybe list those under Base Concept? or not at all?)Preview | Diff