transformability features

[Matt Garrish]

The other question I have for the group relates to the transformation properties. I apologize in advance if I’m misunderstanding a key concept of these, as I believe I was lost in epub land while the displayTransformability property became a part of the accessibility features.

 

That said, my confusion looking at how to apply the properties has to do with a sense of interrelation I see between displayTransformability, resizeText and highContrast. While reviewing, it struck me that resizeText and highContrast are aspects of display transformability, so what makes displayTransformability unique? Is it all the things that aren’t covered by other values?

 

The definition didn’t help alleviate my concerns, as it says display transformability indicates “[t]he document is set up for CSS display transformability”. How are documents set up to meet this requirement when any user agent that allows custom style sheets allows the appearance of html content to be changed? What about other documents where css isn’t the styling language, why would tagged pdf be a subclass?

 

To make a long story shorter, it seems to me like the following hierarchy would be clearer:

 

• displayTransformability – the appearance can be controlled regardless of how that is done
• displayTransformability/resizeText – more specifically that text is known to be controllable
• displayTransformability/highContrast – same but for contrast levels

 

Subclassifying the nature would allow other statements to be made in a similar fashion in the future, like colour control or line height, without further eroding what displayTrasnformability means.

 

I have another question about these properties, but I’ll send it in another email. Feel free to set me straight here if you don’t agree with this interpretation.

 

Matt

[Liddy Nevile]

I agree with this although I am still really wondering if there is
something even better we could do with transformability ...

Liddy

> --
> You received this message because you are subscribed to the Google
> Groups "Accessibility Metadata Project" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to a11y-metadata-pr...@googlegroups.com.
> To post to this group, send email to a11y-metad...@googlegroups.com
> .
> For more options, visit https://groups.google.com/groups/opt_out.

[Anastasia Cheetham]

Hi, Matt,

These are good questions. Looking through the spec in light of your questions, I'm getting confused :-) We should probably make sure we all agree on what we all understand, and then improve the language of the specification to better convey that understanding.

So first I'll go through your questions and respond inline with my current understanding. Please know that I'm not necessarily advocating for things, just expounding/musing on what I think things mean.

On 2013-12-04, at 1:40 PM, Matt Garrish wrote:

While reviewing, it struck me that resizeText and highContrast are aspects of display transformability, so what makes displayTransformability unique? Is it all the things that aren’t covered by other values?

My understanding of the difference is:

displayTransformability is specifically for CSS-enabled transformability, whereas the more specific terms (e.g. highContrast) can be used for things that a) don't have CSS-based presentation, or b) are specifically in the form specified (e.g. "this is a large text version of the resource" as opposed to "this resource can be enlarged because it uses CSS").

Does that make sense, and is that the same as anyone else's understanding?

There does seem to be an overlap between "displayTransformability" and, say, "resizeText/CSSEnabled." I suppose the latter might be used when it's known that size is done through css, but other display properties are not? Maybe "displayTransformability" is intended as a shorthand for saying "everything is transformable via CSS" so that you don't have to list contrast, text size, etc. individually?

The definition didn’t help alleviate my concerns, as it says display transformability indicates “[t]he document is set up for CSS display transformability”. How are documents set up to meet this requirement when any user agent that allows custom style sheets allows the appearance of html content to be changed?

I think the point is that only documents that are properly styled using CSS would be properly transformed by custom stylesheets, so saying "displayTransformability" is saying "this document uses CSS for its styling, so you can transform it however you want using CSS."

What about other documents where css isn’t the styling language, why would tagged pdf be a subclass?

Maybe I'm missing something, but I don't see where it says taggedPDF is a subclass of displayTransformability. I only see taggedPDF as a subclass of resizeText, and in that case it's an alternative to CSSEnabled, i.e. the resizeText could be provided either through CSS or tagged PDF.

To make a long story shorter, it seems to me like the following hierarchy would be clearer:

 

• displayTransformability – the appearance can be controlled regardless of how that is done
• displayTransformability/resizeText – more specifically that text is known to be controllable
• displayTransformability/highContrast – same but for contrast levels

 

Subclassifying the nature would allow other statements to be made in a similar fashion in the future, like colour control or line height, without further eroding what displayTrasnformability means.

I might be misunderstanding your proposal, but it looks to me as though it loses the ability to distinguish between CSS and non-CSS stuff. For example, if all we say is "displayTransformable," does that mean I can use CSS to transform the display? What it it's a tagged PDF document? Will my custom CSS stylesheet work on it? 

-- 
Anastasia Cheetham                    a...@anastasiacheetham.ca
Inclusive Design Research Centre              OCAD University

[Matt Garrish]

Thanks for the responses, Anastasia!

 

Right, I’m proposing a model that would take css specificity out of the equation. You don’t have to agree with that part, but I just found it less likely to cause confusion if the current name is kept.

 

I think you’re running into the same questions I had, though. What properties are display transformable as opposed to text resizable. Are font family, font size, line height, and word space collected under resize text? And everything else is a transformable property? We haven’t clearly laid out where the boundaries are, or even when you set one and not the other. I didn’t put in always having to set both both resizeText and displayTransformability just because the text is transformable by css, but that seems to be the inclination.

 

I still have a problem with css being the only first-class citizen. No other format can be transformed, or the ability to transform it is inconsequential, is what it suggests. There’s no ability to modify the value with some sub-semantic, because everything now has to tie back to css.

 

It’s also not clear what is accessible about display properties being manipulable when they have no appreciable effect. Such a broad statement as CSS can be changed waters down the usefulness, as someone could just see if the resource is html, svg, etc. and get as much information about whether it will be useful to them.

 

The original IMS definition of the property provided a mechanism for being specific about what properties could be controlled, which is the kind of simplicity I like. Every time I try to build a mental model that allows css to exist separately from text resizing and other display properties I get bogged down, though.

 

Matt

[Anastasia Cheetham]

On 2013-12-10, at 7:41 PM, Matt Garrish wrote:

Right, I’m proposing a model that would take css specificity out of the equation. You don’t have to agree with that part, but I just found it less likely to cause confusion if the current name is kept.

Ok, thanks for the confirmation. I don't necessarily disagree; I'm still formulating my opinion. My comments were meant to simply illustrate what my current understanding is of what the terms mean, and to reflect the process that came up with them.

 

I think you’re running into the same questions I had, though. What properties are display transformable as opposed to text resizable. Are font family, font size, line height, and word space collected under resize text? And everything else is a transformable property?

I would say no: font family, line height and word spacing are NOT collected under resize text (though font size is). These are different transformations, which fit under the "transformable" umbrella. 

I still have a problem with css being the only first-class citizen. No other format can be transformed, or the ability to transform it is inconsequential, is what it suggests. There’s no ability to modify the value with some sub-semantic, because everything now has to tie back to css.

That is an excellent point. I'm guessing that the specific mention of CSS came out of a headspace that was focussing primarily on web-based use cases, but we shouldn't be that restrictive.

 

It’s also not clear what is accessible about display properties being manipulable when they have no appreciable effect. Such a broad statement as CSS can be changed waters down the usefulness, as someone could just see if the resource is html, svg, etc. and get as much information about whether it will be useful to them.

Well, I guess the thinking (which was, admittedly, a bit restricted to web resources) was that if styling was provided through CSS, then anything could be transformed into whatever the user wants, which is pretty much the definition of accessible :-) We don't know what the user wants or needs, so it's not for us to define what's accessible and what's not.

The original IMS definition of the property provided a mechanism for being specific about what properties could be controlled, which is the kind of simplicity I like. Every time I try to build a mental model that allows css to exist separately from text resizing and other display properties I get bogged down, though.

Yeah. I think we were trying to simplify it, to reduce it from a laundry list of possible things to something more simple, but I see your point.

So, in light of all this excellent, patient discussion, back to your original proposal:

• displayTransformability – the appearance can be controlled regardless of how that is done
• displayTransformability/resizeText – more specifically that text is known to be controllable
• displayTransformability/highContrast – same but for contrast levels

I think I'm ok with this, if we expand the possible extension values to include some of the things you mentioned above. If implementers don't want to be bothered with the complexity, they can just say "displayTransformability" and leave it with that, but if they want to provide more specifics (for example, if it's a ebook that can do size and colour, but not font family), then they have the ability to do that.

What does everyone else think?

[Matt Garrish]

Slowly catching back up after a double-whammy of illnesses this week, I think highContrast should probably live on its own but remove any mention of the user altering the content to make it conform (and be highContrastDisplay if we’re going to have highContrastAudio).

 

If the content meets WCAG SC 1.4.3, it’s good to be able to indicate that. If the user has to fiddle with foregrounds and backgrounds to achieve sufficient contrast, it sounds more like a displayTransformability feature.

 

I’m going to think about resizeText some more, in light of it not being tied to CSS. If we can find wording that makes the control not dependent on user manipulation of the formatting language, then displayTransformability could become the value that means you can manipulate but you have to know what you’re doing. I keep thinking S/M/L text options for a site versus having to apply custom style sheets.

 

displayTransformability would still allow a subclass of properties to indicate what is controllable, but it would isolate the problem I have with CSS mixing through all three right now. It would become the advanced user option, in other words.

 

At least another option.

 

Matt

 

From: Anastasia Cheetham

Sent: Wednesday, December 11, 2013 2:09 PM

To: Matt Garrish

Cc: a11y-metad...@googlegroups.com

Subject: Re: [a11y-metadata-project] transformability features

 

[Matt Garrish]

Or what about renaming resizeText to textControl, where it means that the user is provided the ability to control any of size, family, height and spacing?

 

That way we shift the meaning away from what is accomplished (which can be done by mutliple means) to how you accomplish it. displayTransformability can also specify the same properties, but it would be the more technical sense of altering by user style sheets. Although, part of me thinks this name should change to cssTransformability.

 

Or an alternate proposal to my previous:

• highContrastDisplay – the content is formatted to meet SC 1.4.3
• textControl – the content includes embedded controls for altering the text
• cssTransformability – the content display can be manipulated by user style sheets, with the option to sub-specify which css properties are controllable

Would that better align with the original group ideas?

 

Matt