W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > April to June 2015

Re: H86: Providing text alternatives for ASCII art, emoticons, and leetspeak

From: Michael Gower <michael.gower@ca.ibm.com>
Date: Tue, 28 Apr 2015 16:12:33 -0700
To: Steve Faulkner <faulkner.steve@gmail.com>
Cc: Andrew Kirkpatrick <akirkpat@adobe.com>, Eric Eggert <ee@w3.org>, "w3c-wai-gl@w3.org" <w3c-wai-gl@w3.org>
Message-ID: <OFA75172EB.8CA4220E-ON85257E35.0077D60C-88257E35.007F7BAA@ca.ibm.com>
Steve, a number of items on the HTML5 common idioms draft page have been on
my list to write about, so I'll take the time to respond to the example on
breadcrumb markers (4.12.2). Let me know if this should spawn a new thread.

Trying to define what use is "contrary to meaning" for a character can get
interesting. For breadcrumbs, the Greater Than symbol (">") has been used
for this and similar constructs for some time. I'd argue it is a meaningful
convention for many users. Besides the obvious visually affordance provided
with the pseudo right arrow look, the "greater than" meaning even conveys
some sense of hierarchy or sequence. Same idea with the fairly set
convention of its use when indicating navigating in menus (e.g.,"Use
Tools>Options>Preferences"). It's not perfect, but if we're going to
replace it, I want to promote something clearly better.
I'm troubled by the advocated preference in the document, which proposes
replacing the > with the right arrow symbol @ . I don't feel it conveys any
more meaningful visual meaning in the context of a breadcrumb trail -- it's
certainly more unconventional -- and JAWS announces the symbol as
"rightwards arrow". I'm not sure how that is any better for readability or
For the rest of the proposed solution, I think the use of list is good. But
I also think that if the document is advocating a use of a list, there are
two considerations: 1) the nav element should be labeled breadcrumb, to
provide context; 2) once that context is established through the label and
the list, any use of a visual separator in this context becomes decorative.
It seems to me a better approach would be some purely visual separator
( with a null ALT, since the list structure already provides the
programmatic information). It would be much more readable.
This all still supports the main position you were advocating -- cutting
down on the use of characters contrary to meaning. But the approach I'm
recommending (no character at all) would be more consistent with that
message, I think.

Michael Gower
Senior Consultant
IBM Accessibility

1803 Douglas Street, Victoria, BC  V8T 5C3
voice: (250) 220-1146 * cel: (250) 661-0098 *  fax: (250) 220-8034

From:	Steve Faulkner <faulkner.steve@gmail.com>
To:	Andrew Kirkpatrick <akirkpat@adobe.com>
Cc:	Michael Gower/CanWest/IBM@IBMCA, Eric Eggert <ee@w3.org>,
            "w3c-wai-gl@w3.org" <w3c-wai-gl@w3.org>
Date:	2015-04-28 08:25 AM
Subject:	Re: H86: Providing text alternatives for ASCII art, emoticons,
            and leetspeak

On a somewhat related current webaim thread (where this technique is cited)

It would be worth considering putting in some advice around use characters
for decoration or use that is contrary to meaning.

I see this a lot and would be good to have a technique to point to (i feel
a pull request coming on)

note: html5 has this advice in relation to right angle brackets used as
breadcrumb markers

  The use of the right angle bracket symbol ">" to indicate path direction
  is discouraged as its meaning, in the context used, is not clearly
  conveyed to all users.




HTML 5.1

On 28 April 2015 at 15:55, Andrew Kirkpatrick <akirkpat@adobe.com> wrote:
  I agree with questioning whether it is worth calling out Leet.? It may
  not be our greatest challenge in making accessible content.

  Re: the leet, I was wondering about the leet text myself earlier and
  apparently I・m a total 733t n00b (that・s :Leet Noob; for anyone who
  hasn・t done the extensive 3 minutes of research I have) and wasn・t aware
  that the :xorz; suffix is for emphasis.


  I・d be ok removing the leet example.? What do people think about example
  1?? If all we were left with using abbr were actual examples of
  unambiguously proper usage of the abbr element that wouldn・t be so badK


  From: Steve Faulkner [mailto:faulkner.steve@gmail.com]
  Sent: Tuesday, April 28, 2015 10:45 AM
  To: Michael Gower
  Cc: Eric Eggert; w3c-wai-gl@w3.org

  Subject: Re: H86: Providing text alternatives for ASCII art, emoticons,
  and leetspeak

  Hi all,

  checking using a leet speak encoder

  Austin Rocks = 4u571n r0ck5 (basic leet)

  while it is not a bad idea to give examples of how we can provide acess
  to content for some users, it should be clearly stated that this is only
  a partial solution and a basic solution that provides equal access should
  be provided


  4u571n r0ck5 (Austin Rocks)

  on use of <abbr>

  HTML5 states:

  The abbr element represents an abbreviation or acronym, optionally with
  its expansion.

  if the leet speak is not an abbreviation or acronym it shouldn't be used
  to provide the alternative.

  On use of the title attribute: its a notoriously poor UI feature for many

  has details.

  the HTML5 spec provides a warning about title:

  A related question is: is it worth calling out leet speak? I had to go
  and look it up, I can't recall seeing it used, but I do live under a




  HTML 5.1

  On 28 April 2015 at 15:18, Michael Gower <michael.gower@ca.ibm.com>

  As a new member of this group, I guess I'll take the opportunity to enter
  the fray on this.

  ";what・s wrong with the abbr example?;
  Example three in H86 is <abbr title="Austin Rocks">Au5t1N r0xx0rz</abbr>
  The second part of the Leet looks to me like Rocksers -- kind of a mashup
  of rockers and scissors. I believe the originally point may have been
  that the English equivalent is not actually "Rocks" (that, or the Leet
  should be r0(k5 )

  At any rate, the discussion has now moved to whether ABBR is suitable to
  use for surfacing ALT. I agree it is a hack. The Leet is not an
  abbreviation. By the same token, the second item in example 1 should also
  be removed: <abbr title="fright">=8-0</abbr>

  However, I'm with Eric on two points: 1) the fact screen readers don't
  implement something by default is not a reason to not implement the
  technique if it is legitimate; 2) other folks, including those with
  cognitive disabilities, can derive benefit from forms of alternative
  information which are not historically available via the user agent

  In this situation, the ABBR technique is attractive because it is
  visually indicated by most user agents (as a minutely dashed underline)
  and provides an affordance via hover to expose the TITLE information to
  mouse users. So I think what is called for is for this matter to be
  flagged to the Cognitive TF so they can deal with the multiple questions

  Personally, I think using the TITLE as a reinforcement on most uses of
  ALT makes a lot of sense. TITLE is valid on virtually all elements, so
  can be added wherever ALT is used to expose the additional meaning to
  mouse users. My one caution is that I've found that some screen readers
  will announce both the ALT and TITLE if the strings are not identical. So
  that would need to be part of the guidance offered.

  That doesn't solve the lack of strong visual affordance for the TITLE or
  the problem with keyboard users not being able to expose the value. But
  as Eric states, "While there may be a user group that isn・t helped using
  a technique, we shouldn・t rule it out for other user groups."

  If I've failed to follow any etiquette of the maillist, please feel free
  to advise me privately.

  Michael Gower
  Senior Consultant
  IBM Accessibility

  1803 Douglas Street, Victoria, BC ?V8T 5C3
  voice: (250) 220-1146 * cel: (250) 661-0098 * ?fax: (250) 220-8034

  From: ? ? ? ?"Eric Eggert" <ee@w3.org>
  To: ? ? ? ?"Andrew Kirkpatrick" <akirkpat@adobe.com>
  Cc: ? ? ? ?"David MacDonald" <david100@sympatico.ca>, "Steve Faulkner" <
  faulkner.steve@gmail.com>, "w3c-wai-gl@w3.org" <w3c-wai-gl@w3.org>
  Date: ? ? ? ?04/28/2015 05:52 AM
  Subject: ? ? ? ?Re: H86: Providing text alternatives for ASCII art,
  emoticons, and ? leetspeak

  On 28 Apr 2015, at 14:22, Andrew Kirkpatrick wrote:

  > My question to Steve that he may have missed was ;what・s wrong
  > with the abbr example?; but David you seem to be raising an argument
  > for not using abbr, which would suggest also removing H28
  > (http://www.w3.org/TR/2015/NOTE-WCAG20-TECHS-20150226/H28).

  Just a quick thought mainly for the H28 discussion (I am not an ASCII
  art connoisseur and don・t know exactly about leetspeak):

  I think this is more a screen reader bug and I would consider adding the
  information there is better practice than leaving it out completely,
  even if the user needs to activate the feature in assistive

  Also this has implication for people with cognitive disabilities, for
  example, that can・t get to descriptions. While there may be a user
  group that isn・t helped using a technique, we shouldn・t rule it out
  for other user groups. It might also be provided to screen reader users
  by default in the future.


  > Any additional information is appreciated!
  > Thanks,
  > AWK
  > From: David MacDonald [mailto:david100@sympatico.ca]
  > Sent: Monday, April 27, 2015 6:29 PM
  > To: Steve Faulkner
  > Cc: w3c-wai-gl@w3.org
  > Subject: Re: H86: Providing text alternatives for ASCII art,
  > emoticons, and leetspeak
  > Agree that we could drop the abbr. It's kind of a hack, and JAWS has
  > abbr support turned off by default, so the abbr may not even speak.
  > Cheers,
  > David MacDonald
  > CanAdapt Solutions Inc.
  > Tel: ?613.235.4902
  > LinkedIn<http://www.linkedin.com/in/davidmacdonald100>
  > www.Can-Adapt.com<http://www.Can-Adapt.com>
  > Adapting the web to all users
  > ? ? ? ? ?Including those with disabilities
  > If you are not the intended recipient, please review our privacy
  > policy<http://www.davidmacd.com/disclaimer.html>
  > On Fri, Apr 24, 2015 at 9:50 AM, Steve Faulkner
  > <faulkner.steve@gmail.com<mailto:faulkner.steve@gmail.com>> wrote:
  > http://www.w3.org/TR/WCAG20-TECHS/H86.html

  > suggest adding ARIA-fied example (from html5 spec)
  > <figure role="img" aria-labelledby="fish-caption"
  > <pre>
  > o ? ? ? ? ? .'`/
  > ? ' ? ? ?/ ?(
  > O ? ?.-'` ` `'-._ ? ? ?.')
  > ? ?_/ (o) ? ? ? ?'. ?.' /
  > ? ?) ? ? ? ))) ? ? >< ?<
  > ? ?`\ ?|_\ ? ? ?_.' ?'. \
  > ? ? ?'-._ ?_ .-' ? ? ? '.)
  > ?jgs ? ? `\__\
  > </pre>
  > <figcaption id="fish-caption">
  > ?<cite>Joan G. Stark, "fish"</cite>.
  > ?October 1997. ASCII on electrons. 28}8.
  > </figcaption>
  > </figure>
  > Also question the use of <abbr> in this technique:
  > <abbr title="Austin Rocks">Au5t1N r0xx0rz</abbr>
  > --
  > Regards
  > SteveF
  > HTML 5.1<http://www.w3.org/html/wg/drafts/html/master/>


  Eric Eggert
  Web Accessibility Specialist
  Web Accessibility Initiative (WAI) at Wold Wide Web Consortium (W3C)

Received on Tuesday, 28 April 2015 23:13:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 16 January 2018 15:34:19 UTC