[Skeleton] Add component proposal

[assuncaocharles]

Skeleton is implemented by few libs and it seems to have no agreement around implementation or even naming:

• Ant Design
• Semantic UI
• Fabric UI

I want to suggest to add it standard proposal to open-ui

Proposal #133

[gregwhitworth]

Thanks for raising this issue @assuncaocharles - looking through the research there doesn't seem to be too much uniformity of the actually produced content. There is obviously usage of a skeleton component but it is apparent that it varies wildly based on usecase for the skeleton. @una and I discussed this general concept recently and I like for her to weigh in with her thoughts as well. Ultimately, I'd like to get this on the agenda for the next conference call to resolve on. I'm not completely sold that there is enough overlap across component libs to warrant this in Open UI but that is solely my opinion.

[assuncaocharles]

Hey @gregwhitworth

I understand there's no enough overlap, looks like most of libs have some similar base structure differing on the boilerplates or usage composing them. The idea would be to define the standard for this base structure which can be used to build the other templates we can see in all other libraries. Correct me if I am wrong but the open ui idea is exactly to document or propose standards right?

[una]

A "skeleton" is a UX pattern -- not a UI pattern. There is no UI standard for this. A skeleton can be used for:

• a blog post card
• user profile
• stock chart
• header
• standalone image
• form
• comments / feed

or really any other UI element or grouping of UI elements that are likely to be server-side rendered.

Therefore, I think that "skeleton" as an ARIA value is valid and interesting, but I don't think we can associate a generalized UI with a skeleton. I feel the best solution would be to propose ARIA attributes that define "skeleton" or "replaced" element instead of design an HTML element (which would require UI).

[gregwhitworth]

Therefore, I think that "skeleton" as an ARIA value is valid and interesting

Ooooh, I like this idea.

The idea would be to define the standard for this base structure which can be used to build the other templates we can see in all other libraries.

You're not technically wrong here, it's more of the ROI here to @una point there are so many potential utilizations that we'll need to add numerous attributes as currently there is only the option for shape & lines. Which isn't necessarily a bad start and I think it's a fine proposal I just personally lean towards this not being a great candidate to standardize on due to the lack of overlap and how the skeleton component is so contextual.

That said, we're simply two voices here so I think it's fine to put this on the agenda to allow others to weigh in and us get a resolution on it.

@assuncaocharles what do you think about the aria role being defined to provide feedback to the user that this content will be swapped out (eg: placeholder content)?

[assuncaocharles]

@assuncaocharles what do you think about the aria role being defined to provide feedback to the user that this content will be swapped out (eg: placeholder content)?

It makes sense, it's basically part of the proposal I wrote inspired by https://vuetifyjs.com/en/components/skeleton-loaders/#accessibility

[chrisdholt]

@gregwhitworth @assuncaocharles Did you happen to consider this as an indeterminate progress control instead of "alert"? While it's visually styled differently, it seems as though the intent and implied indeterminate loading state would be the same with these types of controls (skeleton, shimmer, etc).

[assuncaocharles]

@gregwhitworth @assuncaocharles Did you happen to consider this as an indeterminate progress control instead of "alert"? While it's visually styled differently, it seems as though the intent and implied indeterminate loading state would be the same with these types of controls (skeleton, shimmer, etc).

The problem with role="progressbar" is that it will involve to use some other aria attributes together such as aria-valuemin, aria-valuemax, aria-valuenow. Also semantically it's not something that is actively progressing, it's just a temporary placeholder, can even e used in cases to toggle content visibility etc.

[gregwhitworth]

I would like to spin up a new issue for the aria proposal so that I can loop in the ARIA WG on that one so let's scope this to if we should include Skeleton in Open UI or not. I think the discussion that we had on the telecon will illuminate if we can create a meaningful definition for Skeleton. Since we're considering it for an aria role I think we should be able to.

[gregwhitworth]

@assuncaocharles This was discussed in general with card as well. Ultimately it comes down to, is there enough overlap across component libraries that you can derive an anatomy. Based on the research you've put together I don't think that is the case.

However, we also discussed on the call that there is still value in landing content that is leveraged consistently in the industry. So why don't we start there with answering the following questions:

1. Is skeleton utilized consistently across component libs/design systems? If so, what is the definition of this component in a general sense?
2. Is there enough overlap in utilization to allow for a defined anatomy?

Based your answer to the above two questions, based on your research, I think we can figure out next steps.

[assuncaocharles]

Hey @gregwhitworth

1. Is skeleton utilized consistently across component libs/design systems? If so, what is the definition of this component in a general sense?

There's many libs who implements it ( Semantic, Antd, Fabric, Material ) and it's a common component I would say.

2. Is there enough overlap in utilization to allow for a defined anatomy?

They diff in which boilerplates they offer, e.g. Semantic offer Skeleton.Paragraph while Antd also has Skeleton.Image so in general all boilerplates could be achieved by the proposal here having line and shape

[chrisdholt]

@assuncaocharles We've been looking at this in FAST and I think we have a fairly interesting and flexible approach here. We're in the process of creating our spec, so I can't link to that - but I will link to the overall proposed path forward, which I think we'll take from a flexibility standpoint: microsoft/fast#3770 (comment)

I think this would allow for individual parts, as you've noted above, but also provides a slot to pass a concept of "templates" which could be something like an SVG mask or even a PNG at worst. If I have a design team or have the ability to create an SVG mask, I can pass that and get a complex or more composed skeleton. Alternatively, I can create something like Skeleton.Paragraph or Skeleton.Image using the shapes and compose those. Technically, I could slot in markup with some transparent shapes.

While we don't have this implemented yet, I figured I would pass along our proposed implementation as I think it provides quite a bit of flexibility in terms of implementation and will scale nicely.

[chrisdholt]

While #169 is closed with no action, I did have a thought today on possibly using aria-roledescription for our Skeleton guidance since there isn't a formal role.

The new aria-roledescription property provides content authors a mechanism to over-ride the default role name announced by screen readers with one that is potentially more meaningful to the task or context of use.

@gregwhitworth @una @assuncaocharles @melanierichards thoughts on this approach?

[una]

I'm wondering if we would want the role name announced at all since it holds no meaningful content? That being said, the role would be stating that content is coming... I'm in two minds about it.

[melanierichards]

+1 to @una, we don't need a role announcement here since it wouldn't add meaning for the user.

W/r/t elevating the status of incoming content, I think generally something like aria-busy in this context will be a little too noisy, especially given there will likely be several skeleton components in a document. Adding something like aria-busy is probably something that should be added in a specific and well-considered context instead of componentized (IMHO).

[assuncaocharles]

+1 to @una

Worth to mention how Carbon Design solved this by using

role="status"
aria-live="assertive"
aria-label="loading {components name}"

carbon-design-system/carbon#4310

[chrisdholt]

Thanks all - @assuncaocharles solid example. I would probably leave the aria-live up to those with context of the experience as assertive may not always be reasonable. Curious of others thoughts on the above example :)

[melanierichards]

Yeah, basically anything that pushes status through the AT on the loading state of the skeleton should be decided on a case-by-case basis, rather than stored in the component design as a default (IMHO). There are cases where that could be more overwhelming than it is meaningful to the user.

[github-actions]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.