Spoiler DW-tag

[magibrain]

Title:
Spoiler DW-tag

Area:
DW custom tags

Summary:
Add a tag to easily add spoilertext to a post.

Description:
I suggest a [spoiler][/spoiler] tag which would automatically generate spoilertext (often black text on a black background, so that a user can choose to highlight it to read it), with a hidden-from-screen-display but screen-reader-accessible (possibly using WebAIM's hidden content trick - http://webaim.org/techniques/css/invisiblecontent/ ) link to skip the spoilered content. The rough format I've been using in my posts is this (brackets flattened because preview didn't like < and > codes):

[a href="#skip_spoiler_1" style="width:1px; height:1px; position:absolute; left:-10000px;"]skip spoiler[/a][span style="color:#000; background-color:#000;"]SPOILERS SPOILERS SPOILERS[/blockquote][a name="skip_spoiler_1" /]

It seems that the following code:

[spoiler]SPOILERS SPOILERS SPOILERS[/spoiler]

would be much cleaner, and guarantee accessibility for people using spoilertext who might not otherwise consider screenreaders.

As for drawbacks... I'm not sure how many people actually use spoilertext on a regular basis, I don't know if color choice would be controversial, I'm not entirely happy with the disparallel between functionality for sighted and screenreader-using folk (where people reading visually have to take action to see the spoilered content, but people using a screenreader have to take action to *avoid* being spoilered), the outputted HTML is still a little bloated, the trick to not display the skip link is a kludge (because screenreaders have erratic handling of both visibility:hidden and display:none), and I imagine it would get extremely ugly if used on a large patch of text. But it'd be cool to hear discussion on any/all points. :)

Poll #9002 Spoiler DW-tag

Open to: Registered Users, detailed results viewable to: All, participants: 101

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
46 (45.5%)

Should be implemented with changes. (please comment)
22 (21.8%)

Shouldn't be implemented.
10 (9.9%)

(I have no opinion)
22 (21.8%)

(Other: please comment)
1 (1.0%)

Comments

[denise]

This was previously suggested at http://dw-suggestions.dreamwidth.org/31862.html and rejected for being something that couldn't be implemented in a way that would be usable for all users (mobile devices in particular) and for being something that could be achieved through other means. I'm letting it through for rediscussion since it's been two years or so since the last discussion and somebody may have a good argument to overcome the problems!

[facetofcathy]

I think you have to do a javascript onclick method for this, or else too many people either can't see the spoiler text or they see it even when they don't want to. Taking some points from other comments...

So what if:

The spoiler text starts out visibility: hidden so there's space for it in the layout, but no one sees it. It shouldn't show up in plain text or in an email content version of the post (some people email themselves posts so they can read them not logged in), screen readers don't read it.

Only those people who want to read it can make it appear by clicking a button the code inserts in front of the hidden content. Click it again and it's hidden again. This way the spoiler text can just be in the default content colours and you don't have to fuss about colour combos. It could be made visually distinct with a text-colour border or something if you wanted to make it obvious that it's special text.

Drawbacks:

You'd need functional javascript to get it to show up.
A miss click shows the spoiler.
Might not work on every device? I'm pretty sure screen readers will read something made visible by JS in this way, particularly if the button is before the spoiler text, but do all devices?
Inserting the button into the post takes up space the post creator might not be expecting to be used.

[rho]

I see this as something that's best achieved by extending the functionality of the cut tag, rather than by adding a new tag. As it stands, the cut tag can already be used to have text be hidden by default but shown after an action by the reader, which seems to fit the bill perfectly.

So, what problems currently exist that stop it being used that way? The largest is that the page for a specific entry (eg http://dw-suggestions.dreamwidth.org/1303478.html) automatically expands all cut tags. If this behaviour were changed, would that work to take away the need for this? What other problems are there that make people want to use this method of hiding spoilers rather than the cut tag?

[susanreads]

I incline to "Yes", with laitaine's method of choosing colours, but rho's alternative solution might be better. I think people using visual browsers and mice expect to see highlight-to-read spoiler text because that's what you get elsewhere, and it's pretty easy to code ... if you don't care about accessibility. I've got a bookmark to the cheat-sheet for an accessible method, and it's really complicated. A pseudo-html tag would take away a lot of effort in applying the cheat-sheet, and could be updated if new methods became available, but it would still be some clumsy-looking code. An extra parameter on a cut-tag to make it stay closed unless specifically opened would be spiffy.

[opusculus]

I think having a DW-default way of marking spoilers would be really nice, honestly. Even if it isn't the most accessible thing ever, it's still going to be more accessible than what people come up with on their own. I know I'm too lazy to ever do more than font color="white", and I know that's a terrible way to do it.

I'd be mildly against a cut-tag version of this, at least implemented as specifically spoilery. I assume it'd have to be expanded into being able to cut comments, and that's going to run into problems with the expand all comments feature and people using it to cut pictures and other non-spoilery uses, and while I don't necessarily object to that, I think that's a fairly different suggestion that I haven't really thought out enough to properly say. And my prior experience in anime forums is that cut tags labelled specifically as spoilers bug me to no end when people promptly start using them for non-spoilery reasons, even when I agree with the non-spoilery reasons. So I'm a little wary.

[zeborah]

If the technical and accessibility issues can be surmounted, I would love and regularly use a spoiler/trigger pseudo-tag; as it is I have to open a file where I've stored a template for one that I got from a friend of a friend somewhere some while back...

[sally_maria]

I think it would be a very useful feature, though I have no strong feelings about how it is implemented.

It would be good to have it work in such a way that cross-posting didn't break the spoiler protection, however that might work.

[dragonfly]

I think it shouldn't be called a "spoiler" tag, since it could be used to mask triggers and other things that aren't spoilers. Maybe just "mask."

As far as issues of accessibility, I don't have any solution to suggest for that.

But FWIW, I'd like to have an easy way to do this, rather than playing with colors and various scripts.

[jeshyr]

( It's so cool that everybody thinks about accessibility of suggestions here! \o/ )

I do like this idea and I do agree that even if we can't implement it perfectly for everybody that we'll probably end up with something that's better than what's already being hand-coded in many cases for spoilers and potential triggers.

"Mask" is a great nonspecific nonnegative term to use and leaves the field open for users to find other uses for it as well, as they always do!

I do think that this is a separate use-case from existing cut tags because it's often used inline in the case of fic headers especially, for example to hide warnings that the reader may not want to use. Cut tags are great for hiding a paragraph or more but really awful for hiding just a few words which are part of an otherwise visible paragraph. This is akin to the HTML division between 'div' and 'span' in my head. Whether it's implemented using the shortcut of <cut type="inline" ... or as another different tag <mask ..., the use case *is* currently different and I think it should be considered as such. It does occur to me that as inline-expanding cut tags evolve and this (if implemented) evolves they may eventually come together in the future and re-merge. In that case, forming the tag as an argument (etc.) to our existing <cut tag would give us the greatest future freedom to change the implementation without confusing people more than is absolutely necessary. The one accessibility use case which hasn't been discussed (as far as I can see upon quick skim) is keyboard-only users who don't use either screen reader or mouse. For these people an "unhide" link or button (perhaps a magnifying glass icon?) which displayed inline before the hidden text may be a solution - this could possibly also help certain mobile device users? I will defer to actual UI designers for how this should look, but I will note that keyboard-only users will not be able to trigger a JavaScript "onClick" block whereas they would be able to trigger a href containing a Bookmarklet-type JavaScript block. This information needs to be confirmed with keyboard-only users and screen reader users, of course! It's academic knowledge to me as I don't use either technology. r

[roadrunnertwice]

I would really love an easy spoiler tag that did the right thing for screenreaders/mobile/everybody. Failing that, I'd like something that did the right thing for as many groups as possible, because the status quo is more bunk than pretty much any of the alternatives.

(I found something tonight that works great on mobile and desktop without needing Javascript, but readers won't get the benefit unless they view the entry in my style, and I won't get the benefit unless the folk I read write their spoiler tags so they'll work with my reading page. That's kind of frustrating.)

suggestion: [lj-spoiler]-type cut with LJ integration

[quartzpebble]

azurelunatic suggested integrations with the [lj-spoiler] tag. [lj-spoiler] does work in comments, and Dreamwidth doesn't currently have a cut-tag for comments. This is something I would find useful, and also something that I would be interested in contributing development effort to (though I would need help on where to start!).