- From: J. Albert Bowden <jalbertbowden@gmail.com>
- Date: Wed, 06 Sep 2017 05:27:04 +0000
- To: "Michael A. Peters" <mpeters@domblogger.net>, w3c-wai-ig@w3.org
- Message-ID: <CAPVQ3_fSyohA9mr5PJH_5B4H7J4cXyCbq+PbRK0Z53pQ1oMGxQ@mail.gmail.com>
the image could be made into a sprite if resource requests are an issue. unicode fallbacks are a good point. On Wed, Sep 6, 2017 at 1:15 AM Michael A. Peters <mpeters@domblogger.net> wrote: > 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/ > > > > > -- Sent from Gmail Mobile
Received on Wednesday, 6 September 2017 05:35:18 UTC