chore(skeleton): added screen reader text - #7716

@thatblindgeye I am not sure if this is the correct place for the span.

We'd want this text to be a direct child of a skeleton. What we could do is allow a way to pass some custom screen reader text inside the card-skeleton.hbs file, and then update this demo to pass that into the card-skeleton instances. We could even have it fallback to some default "Loading card content" text or similar. For this particular demo, whether each card should actually have their own screen reader text is iffy. In certain scenarions it may make sense to do that... for here, we could keep it simple and just apply a screen reader text to the first card.

@mcoker do we intend on ever using the table-skeleton at all? We have a file for it but it's not used anywhere. If we do we'd want to make a similar update there.

@thatblindgeye not that I know of. You're welcome to remove that file if you'd like. I see it's referencing {{#> skeleton-element}} which doesn't appear to exist. FYI, it would be defined either as a file named skeleton-element.hbs OR sometimes we have "inline" partials where we define the partial name and code in some other file, but I searched the repo for "skeleton-element" and didn't see an inline partial anywhere.

If skeletons should always have some text, should we just have some logic in skeleton.hbs that's like this, then we'd just specify skeleton--HasNoText=true for ones we want to omit (like all but the first card in that demo)

{{#unless skeleton--HasNoText}}
  {{#if skeleton--text}}
    {{skeleton--text}}
  {{else}}
    Loading content
  {{/if}}
{{/unless}}

We could do that. Would be handy when there's only one section of a skeleton being used in an example/demo, though we'd just need to make sure to provide more unique text when there's multiple sections that need some sort of content

There is a hbs partial that will generate this element for you - screen-reader.hbs

Will the make the changes.

The naming of this handlebars attribute is pretty close. In a sense they can be similar in naming structure to our React props, one difference being that we'll prefix the attribute with the component and a double hyphen, and the attribute will be pascal case, so something like

That said, implementing the feedback from Coker where the skeleton.hbs file has a default value could be a nice to have, though that could be where you can get into how complex handlebars can be/feel. I wouldn't consider implementing that a priority and would be slightly out of scope so if you want to pass on it that's fine.

If you want to make an attempt, ideally the logic should be:

• skeleton.hbs has logic either where unless skeleton--HasNoText or if skeleton-IsFirstSkeleton (or something), then we either render whatever is passed to skeleton--text or a default string of Loading conternt". We could also just use @partial-blockinstead ofskeleton--text`, though I'd leave that up to Coker if he has a preference as I don't
• From there, within card-skeletong.hbs, the logic you have now would have to be tweaked slightly if we went with the skeleton--text approach, possibly utilizing the handblebars ternary function we have and passing that into skeleton--text to check if card-skeleton--IsFirstCard is true, passing in the loading text here if so or an empty string if not. Coker may have a less complicated approach, though.