search

bkardell / common-panel

An effort to define a new element with clear semantics and separation
14 stars 3 forks source link

significant change suggestions #45

Open bkardell opened 8 years ago

bkardell commented 8 years ago

All,

Based on where we are at with this, with some open challenges, wonky bits and no shadow dom implementation yet either, I worked with @alice on a review and refactor. After a lot of discussion, I think the two of us are in agreement that this might be better... I think there might be a few more things to discuss and I'm actually not 100% sure on the panelset shadow dom, we should probably get someone else to look at/consult there to make sure I didn't flub something up...

In any case, we've wrangled each into separate files in the gist below that explain what the purpose/features are, what you type as an author and what the composed DOM it expands into would be.

https://gist.github.com/bkardell/fdd5944768f0a7e26018b98fb41fc570

ZoeBijl commented 8 years ago

My biggest gripe is that there is no way to have a multi-select panel set; something like <common-panel-set multiple>. Could be very much like how <select> does it.

Another point would be the name. As far as I’m aware, there is no <panel>, <panel-title>, or <panel-set> element. Would it make more sense to change it to that?

Re shadow DOM: a role of tablist shouldn’t wrap the entire list including panels. That said, role of tablist doesn’t make much sense if it’s an accordion. I vaguely recall that being in the APG a few months back, but we’ve done a major revision of the accordion pattern. (please don’t shoot me over the styling of the accompanying code example).

bkardell commented 8 years ago

@MichielBijl

My biggest gripe is that there is no way to have a multi-select panel set; something like <common-panel-set multiple>. Could be very much like how <select> does it.

My original observation in all of this is that there are N visualizations that are only visually different, they are otherwise all functionally the same and therefore have similar a11y concerns. Selecting N and selecting 1 of a set do not seem to share that quality - there are no 'tab' concepts where there are multiple selected to the best of my knowledge, nor carousels. Supporting multiple raises a lot of questions that selecting 1 doesn't. I'm personally of the opinion it's worth figuring out 1 before we worry about multiple.

Another point would be the name. As far as I’m aware, there is no <panel>, <panel-title>, or <panel-set> element. Would it make more sense to change it to that?

<panel> isn't a valid custom element, so if you mean for the prototypes, nay. the others wouldn't be valid proposals as they are custom elements, so if you mean in a standards oriented proposal, nay. But otherwise, this seems like just bikeshedding. I know there are people using the existing one and in the very least I'll keep aliases for the existing ones. Bikeshed away.

Re shadow DOM: a role of tablist shouldn’t wrap the entire list including panels.

All input on this is welcome, solution oriented proposals that don't cause a diff set of problems preferred :)

That said, role of tablist doesn’t make much sense if it’s an accordion.

Depends what you mean by accordion. Pretty sure you are using it in the multi-select context in which case, you're right, see my first comment. Otherwise, whether the thing is visualized horizontally or vertically is largely irrelevant to describing its semantics or functionality as near as we could tell (that's what launched this in the first place after a discussion at TPAC).

ZoeBijl commented 8 years ago

Selecting N and selecting 1 of a set do not seem to share that quality - there are no 'tab' concepts where there are multiple selected to the best of my knowledge, nor carousels.

True, there are no tabs or carousels that allow to select multiple panels. There are accordions that do that though. In a previous conversation you said that could be fixed by having multiple titles and panels. There is some truth in that, but you would lose the ability to move between titles with the arrow keys for example, because the titles/panels aren’t related/grouped.

Bikeshed away.

I thought this was about new native HTML elements, am I wrong?

All input on this is welcome, solution oriented proposals that don't cause a diff set of problems preferred :)

Someone in the a11ySlackers channel linked to an accordion example by @hanshillen and it actually doesn’t seem to matter one bit on the user end (only tested with VO). I’m not sure what the concensus on this is at the moment.