Re: Media Queries & Details/Summary for extended descriptions

James, Florian

let me try to summarize what was discussed, the minutes may not have been very clear. (Tzviya is on vacations this week, ie, way may want to wait for her reaction next week to see if my interpretation is correct…)

1. The media query would be something like

@media( -user-prefers-to-access-details ) {
   … whatever is necessary here, ie, making the content of <details> visible, whereas it is set to invisible otherwise
   … other styling
}

2. The value of -user-prefers-to-access-details would be set in the browser through some browser specific user interface.

Of course, the mechanism should be more general and not specific to the <details> element; I use it for illustrative purposes only. Whether that is some sort of a general accessibility flag or something even more general: to be honest I do not know. Ie, I agree with Florian that it is not, and should not be, specific to the summary issue but, rather, some sort of general feature that I could set like, eg, 'I do not want to see images'.

Florian, I believe user style sheet is different. The styling in this case is still set by the author, incorporating any specificities of the styles for that specific documents. I guess it is also an issue that we cannot expect the lambda user to understand CSS and come up with a decent user style sheet. If the now practically defunct approach of alternate style sheets were around, that would be a different, and possibly working option; I am not sure we can revive that.

To be honest, I do not know whether this is a realistic avenue. But the underlying issue is to provide some decent way of ensuring that while one person can ignore the content of <detail> by defaults, the same document can be seen exactly the other way round by default by another user.

Obviously, this is a much more general and powerful direction for CSS, and I do not know whether it is realistic to expect anything in this direction. (I admit that I did not even think about this until, on the call, I heard that such discussions have already taken place before). But, let me dream: having the browsers providing a set of user interface 'flags' that can be queried from CSS via media queries sounds like a very useful general feature to me...

James, you ask "Couldn't that just be an AT behavior?": I am not sure it is the same (and, consequently, one may not exclude the other). What I believe that would mean is that, by default, the content of the <details> element would be, say, invisible as set by the corresponding stylesheet, but the AT can overrule this and make that content accessible (eg, as text). But is it a good idea to hardwire such behavior into the AT? Isn't that something that the end user could somehow control even if he/she does not use a particular AT, just an average browser instead? It, sort of, feels at another level to me.

Tzviya, Markus, I hope I provided the right interpretation of our discussion...

Cheers

Ivan


> On 9 Feb 2016, at 11:12, Janina Sajka <janina@rednote.net> wrote:
> 
> And here the response from Florian ...
> 
> Florian Rivoal writes:
> 
>> On Feb 5, 2016, at 18:43, James Craig <jcraig@apple.com> wrote:
>> 
>> 
>>> On Feb 4, 2016, at 5:52 AM, Janina Sajka <janina@rednote.net> wrote:
>>> 
>>> Hi, James:
>>> 
>>> Writing off list for now, but with a CC to Florian as this is a question
>>> about creating a binary MQ for show/hide presence of extended
>>> descriptions in HTML Details/Summary ...
>>> 
>>> One piece of the puzzle that Dpub (and ARIA) need in order to move away
>>> from longdesc/Describedat and into using Details/Summary for extended
>>> descriptions is a way for the user to configure their browser to alert
>>> them when a particular image has a Details/Summary which is further
>>> identified via ARIA as an extended description.
>> 
>> I'm not sure I understand. Why do you need a new MQ for this? Couldn't that just be an AT behavior?
> 
> Hi,
> 
> Switching between different styles based on a media query, including hiding or showing (in different ways) a summary element sounds possible, but I have a harder time picturing out exactly what the query itself would be responding to.
> 
> Even if we tie MQs to user preferences, which isn't out of question, "For accessibility reasons I want the summary element to be shown rather than hidden" is unlikely to be adopted as an MQ:
> 
> 1) It is way too specific, we cannot have MQs for every design preference in the world. User Style sheets are probably more appropriate for tweaking individual design decisions, possibly per site.
>  summary { display: block !important; }
> vs
>  summary { display:none; }
> 
> 2) Features designed exclusively for accessibility use cases, as opposed to features to be used by everyone and with strong accessibility benefits, tend to be neglected by authors and to have limited benefits.
> 
> 3) There's a privacy aspect to exposing disability related preferences to sites, be it via MQs or other mechanisms, that needs to be taken into account.
> 
> - Florian
> 
> --
> 
> Janina Sajka, Phone: +1.443.300.2200
>    sip:janina@asterisk.rednote.net
>   Email: janina@rednote.net
> 
> Linux Foundation Fellow
> Executive Chair, Accessibility Workgroup: http://a11y.org
> 
> The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
> Chair, Accessible Platform Architectures http://www.w3.org/wai/apa
> 
> 


----
Ivan Herman, W3C
Digital Publishing Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704