W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > July to September 2017

Re: Unicode character for CC symbol?

From: Michael A. Peters <mpeters@domblogger.net>
Date: Tue, 5 Sep 2017 22:08:09 -0700
To: w3c-wai-ig@w3.org
Message-ID: <baa3aa54-33c7-76d2-8c27-950ba8115122@domblogger.net>
It is good enough, but having it in a font is one less resource browser 
request that has to be made.

With webfonts there is a single request for the font and it can contain 
numerous different glyphs that can then instantly be rendered on demand.

But even with webfonts for glyphs it is best to only use glyphs that 
have a standard unicode code point so there is a good chance of them 
being there if the web font doesn't load.

On 09/05/2017 11:48 AM, J. Albert Bowden wrote:
> Any reason why wikipedia's cc icon isn't good
> enough? https://commons.wikimedia.org/wiki/File:Closed_captioning_symbol.svg
> It's public domain...
> Also, if you want to use the font icon, pretty sure they offer svg
> version (if not the conversion is minimal), which you can simply use in
> an <img />.
> More info and canonical source for the cc icon
> here: http://main.wgbh.org/wgbh/hire/symbols.html
>
> Just trying to help.
> Albert
>
> On Tue, Sep 5, 2017 at 1:58 PM, Elizabeth Pyatt <ejp10@psu.edu
> <mailto:ejp10@psu.edu>> wrote:
>
>     Icon fonts can work if ARIA descriptions are added. This basically
>     treats the character as an image and adds an ALT text option.
>     See
>     http://sites.psu.edu/gotunicode/2014/11/18/aria-for-screen-readers-not-able-to-read-symbols/
>     <http://sites.psu.edu/gotunicode/2014/11/18/aria-for-screen-readers-not-able-to-read-symbols/>
>
>     As you might guess, you would want to be strategic in your use of an
>     icon font, this could be a case where the ARIA solution could be
>     useful (or you could use an image with ALT text).
>
>     Hope this helps.
>
>     Elizabeth
>
>
>     > On Sep 5, 2017, at 11:32 AM, Patrick H. Lauke
>     <redux@splintered.co.uk <mailto:redux@splintered.co.uk>> wrote:
>     >
>     > Noting that icon fonts have their own issues, particularly for
>     users who set custom fonts, among other things. See
>     https://cloudfour.com/thinks/seriously-dont-use-icon-fonts/
>     <https://cloudfour.com/thinks/seriously-dont-use-icon-fonts/> and
>     https://speakerdeck.com/ninjanails/death-to-icon-fonts
>     <https://speakerdeck.com/ninjanails/death-to-icon-fonts>
>     >
>     > P
>     >
>     > On 05/09/2017 15:43, Andrew Kirkpatrick wrote:
>     >> It is available in Font Awesome (http://fontawesome.io/icon/cc/
>     <http://fontawesome.io/icon/cc/>) using the private use space in
>     Unicodeā€¦
>     >> Thanks,
>     >> AWK
>     >> Andrew Kirkpatrick
>     >> Group Product Manager, Accessibility
>     >> Adobe
>     >> akirkpat@adobe.com <mailto:akirkpat@adobe.com>
>     >> http://twitter.com/awkawk
>     >> On 9/5/17, 06:07, "Nigel Megitt" <nigel.megitt@bbc.co.uk
>     <mailto:nigel.megitt@bbc.co.uk>> wrote:
>     >>> This seems on the face of it problematic. The trouble is that
>     there is no
>     >>> single representation for the idea of "closed captions"
>     globally. Whereas
>     >>> in the US it might be represented by something like "CC", in the
>     UK where
>     >>> closed captions are known more usually as subtitles, it is often
>     >>> represented by "S". I may be wrong about this but I don't think
>     Unicode
>     >>> would normally create a code point for a glyph that has
>     >>> territory/culture-specific variant forms.
>     >>>
>     >>> Having said that, a globally usable label of some sort that
>     means "this is
>     >>> the button for switching closed captions on and off" could be
>     useful.
>     >>>
>     >>>
>     >>> On 03/09/2017, 22:33, "Michael A. Peters"
>     <mpeters@domblogger.net <mailto:mpeters@domblogger.net>> wrote:
>     >>>
>     >>>> According to
>     >>>>
>     https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FFile%3AClosed_captioning_symbol.svg&data=02%7C01%7C%7C044b96f883e0476fbf5408d4f446d6c7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636402032489256383&sdata=um37Q5hz%2FuCfvJ67yslDrq5qF%2FPPwrRp77uZTxr7mwQ%3D&reserved=0
>     <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FFile%3AClosed_captioning_symbol.svg&data=02%7C01%7C%7C044b96f883e0476fbf5408d4f446d6c7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636402032489256383&sdata=um37Q5hz%2FuCfvJ67yslDrq5qF%2FPPwrRp77uZTxr7mwQ%3D&reserved=0>
>     that
>     >>>> symbol has been released into the public domain.
>     >>>>
>     >>>> It would make sense then for there to be a unicode character
>     for it, in
>     >>>> the technical range (where play and fast forward and pause
>     glyphs exist)
>     >>>> but I could not find one.
>     >>>>
>     >>>> For me where it would be useful is when designing html5
>     players, the
>     >>>> standard audio players in most browsers don't show the CC
>     button even
>     >>>> when there are track elements provided and custom JS to display
>     them.
>     >>>>
>     >>>> If it had a unicode character, I could modify my webfont to
>     include it
>     >>>> there and just specify the character glyph (in a span with title
>     >>>> attribute of course) like I do with the other player control
>     elements.
>     >>>>
>     >>>> I can suggest it to the unicode group but I wanted to make sure it
>     >>>> doesn't already exist and I'm just not finding it, and also if it
>     >>>> doesn't, hear any arguments as to why it might be a bad idea.
>     >>>>
>     >>>
>     >>>
>     >
>     >
>     > --
>     > Patrick H. Lauke
>     >
>     > www.splintered.co.uk <http://www.splintered.co.uk> |
>     https://github.com/patrickhlauke <https://github.com/patrickhlauke>
>     > http://flickr.com/photos/redux/ <http://flickr.com/photos/redux/>
>     | http://redux.deviantart.com
>     > twitter: @patrick_h_lauke | skype: patrick_h_lauke
>     >
>
>     =-=-=-=-=-=-=-=-=-=-=-=-=
>     Elizabeth J. Pyatt, Ph.D.
>     Accessibility IT Consultant
>     Teaching and Learning with Technology
>     Penn State University
>     ejp10@psu.edu <mailto:ejp10@psu.edu>, (814) 865-0805
>     <tel:%28814%29%20865-0805> or (814) 865-2030
>     <tel:%28814%29%20865-2030> (Main Office)
>
>     The 300 Building
>     304 West College Avenue
>     University Park, PA 16801
>     http://accessibility.psu.edu
>
>
>
>
>
> --
> J. Albert Bowden II
>
> jalbertbowden@gmail.com <mailto:jalbertbowden@gmail.com>
>
> http://bowdenweb.com/
>
Received on Wednesday, 6 September 2017 05:08:35 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 6 September 2017 05:08:37 UTC