RE: Support as an SC prefix?

Don’t forget that your icon will need a label per 

F26: Failure of Success Criterion 1.3.3 due to using a graphical symbol alone to convey information

Description
The objective of this technique is to show how using a graphical symbol to convey information can make content difficult to comprehend. A graphical symbol may be an image, an image of text or a pictorial or decorative character symbol (glyph) which imparts information nonverbally. Examples of graphical symbols include an image of a red circle with a line through it, a "smiley" face, or a glyph which represents a check mark, arrow, or other symbol but is not the character with that meaning. Assistive technology users may have difficulty determining the meaning of the graphical symbol. If a graphical symbol is used to convey information, provide an alternative using features of the technology or use a different mechanism that can be marked with an alternative to represent the graphical symbol. For example, an image with a text alternative can be used instead of the glyph. 



Alan Smith

From: Laura Carlson
Sent: Wednesday, March 8, 2017 3:58 PM
To: Jonathan Avila; John Foliot; Alastair Campbell
Cc: WCAG
Subject: Re: Support as an SC prefix?

Hi John, Jon, Alastair, and all,

I agree whole hardily with the concept. We have gone round and round
explaining that author supplies widgets are not required on several of
low vision SCs. So something to call that out from the start would be
a blessing.

But the word "support" by itself is ambiguous. I don't think it would clarify.

Maybe if the handle was longer:

"support X (author supplied widgets not mandated)"

But that gets kind of long.

Here is an idea. I wonder if an icon as part of the handle could help
convey that author supplied widgets are not mandated.

Maybe a pen and gear with a dashed line though them? I am thinking a
dash instead of a solid line as author supplied widgets wouldn't be
required but they wouldn't be outlawed either.

My 2 cents.

Kindest Regards,
Laura

On 3/8/17, Jonathan Avila <jon.avila@ssbbartgroup.com> wrote:
> Ø  @Laura, as I read this, the author would need to ensure "Support" was
> authored into the content, rather than provide the actual support.
>
> John, what I think Laura is saying is that the author could choose to build
> in a widget as a way to meet it rather than supporting it say through
> responsive design.  So either approach could be used.  The word support may
> imply that a widget could not be used if the author so chooses.
>
> Jonathan
>
> From: John Foliot [mailto:john.foliot@deque.com]
> Sent: Wednesday, March 08, 2017 11:26 AM
> To: Laura Carlson
> Cc: Alastair Campbell; WCAG
> Subject: Re: Support as an SC prefix?
>
> Hi Alistair,
>
> Interesting... we would likely have to detail what "Support" would entail in
> our Techniques Section, but I like the general idea.
>
> @Laura, as I read this, the author would need to ensure "Support" was
> authored into the content, rather than provide the actual support. For
> example, @alt text "supports" a screen reader user, but the author is not
> required to provide a tool that surfaces that @alt text, only ensure that
> the conditions are met (i.e. appropriate alt text) when a support tool (aka
> screen reader) is invoked.
>
> (Alastair, is that a correct understanding of your proposal?)
>
> JF
>
> On Wed, Mar 8, 2017 at 7:56 AM, Laura Carlson
> <laura.lee.carlson@gmail.com<mailto:laura.lee.carlson@gmail.com>> wrote:
> Hi Alastair and all,
>
> Interesting idea regarding having a prefix or some other indicator
> that a widget is not required. It would be great to alleviate that
> misconception.
>
> But I'm not sure if "support" is the right word. Why wouldn't  an
> on-screen widget be considered support?
>
> Kindest Regards,
> Laura
>
> On 3/8/17, Alastair Campbell
> <acampbell@nomensa.com<mailto:acampbell@nomensa.com>> wrote:
>> Hi everyone,
>>
>> There is an interesting point raised on github for the SCs which are
>> aimed
>> at authors enabling something without (necessarily) adding on-screen
>> widgets:
>> https://github.com/w3c/wcag21/issues/159#issuecomment-285020097
>>
>> “Maybe the use of the "Support" prefix would be a useful standard to set
>> for
>> the SC titles if an on-screen widget is not required, so that in this
>> case
>> it would be "Support Reflow to Single Column", just as we have "Support
>> Personalization".
>> This would also suggest a rename of 1.4.13 to "Support Printing", for
>> example.”
>>
>> It would be an alternative to the “mechanism is available” language,
>> hopefully leading people away from assuming there would be on-screen
>> widgets.
>>
>> If that were taking on, I think it would lead to:
>>
>> ·         Support linearization (Or ‘Support reflow to single column’)
>>
>> ·         Support printing (Or ‘Support adaptations when printing’ might
>> be
>> more accurate.)
>>
>> ·         Support adapting text
>>
>> ·         Support extra symbols.
>>
>> And possibly others from COGA that didn’t make it to the FPWD.
>>
>> So two questions:
>>
>> 1.       Do you think this approach is helpful? And if so,
>>
>> 2.       Is “support” the right prefix?
>>
>> Kind regards,
>>
>> -Alastair
>>
>> --
>>
>> www.nomensa.com<http://www.nomensa.com><http://www.nomensa.com/>
>> tel: +44 (0)117 929 7333<tel:%2B44%20%280%29117%20929%207333> / 07970 879
>> 653
>> follow us: @we_are_nomensa or me: @alastc
>> Nomensa Ltd. King William House, 13 Queen Square, Bristol BS1 4NT
>>
>> Company number: 4214477 | UK VAT registration: GB 771727411
>>
>
> --
> Laura L. Carlson
>
>
>
> --
> John Foliot
> Principal Accessibility Strategist
> Deque Systems Inc.
> john.foliot@deque.com<mailto:john.foliot@deque.com>
>
> Advancing the mission of digital accessibility and inclusion
>


-- 
Laura L. Carlson