
Recherche avancée
Médias (3)
-
MediaSPIP Simple : futur thème graphique par défaut ?
26 septembre 2013, par
Mis à jour : Octobre 2013
Langue : français
Type : Video
-
GetID3 - Bloc informations de fichiers
9 avril 2013, par
Mis à jour : Mai 2013
Langue : français
Type : Image
-
GetID3 - Boutons supplémentaires
9 avril 2013, par
Mis à jour : Avril 2013
Langue : français
Type : Image
Autres articles (66)
-
Personnaliser les catégories
21 juin 2013, parFormulaire de création d’une catégorie
Pour ceux qui connaissent bien SPIP, une catégorie peut être assimilée à une rubrique.
Dans le cas d’un document de type catégorie, les champs proposés par défaut sont : Texte
On peut modifier ce formulaire dans la partie :
Administration > Configuration des masques de formulaire.
Dans le cas d’un document de type média, les champs non affichés par défaut sont : Descriptif rapide
Par ailleurs, c’est dans cette partie configuration qu’on peut indiquer le (...) -
Gestion des droits de création et d’édition des objets
8 février 2011, parPar défaut, beaucoup de fonctionnalités sont limitées aux administrateurs mais restent configurables indépendamment pour modifier leur statut minimal d’utilisation notamment : la rédaction de contenus sur le site modifiables dans la gestion des templates de formulaires ; l’ajout de notes aux articles ; l’ajout de légendes et d’annotations sur les images ;
-
Diogene : création de masques spécifiques de formulaires d’édition de contenus
26 octobre 2010, parDiogene est un des plugins ? SPIP activé par défaut (extension) lors de l’initialisation de MediaSPIP.
A quoi sert ce plugin
Création de masques de formulaires
Le plugin Diogène permet de créer des masques de formulaires spécifiques par secteur sur les trois objets spécifiques SPIP que sont : les articles ; les rubriques ; les sites
Il permet ainsi de définir en fonction d’un secteur particulier, un masque de formulaire par objet, ajoutant ou enlevant ainsi des champs afin de rendre le formulaire (...)
Sur d’autres sites (5367)
-
how to analyze the binary data of these h.264 packets and organize a h.264 stream to decode them use ffmpeg ?
27 mars 2012, par 丝地 陈Much appreciation to some help with the following issue :
the h.264 packets attached below are received from a decoder,but I am not sure about the details, e.g. the transfer protocol .I've searched some topics similar to this and read the articles of analysis on this topic from the author Cipi and others.Thanks a lot .
but still i can't resolve to analyze the data of these packets .so I issue this problem and hope to get some help.
I'm able to ffmpeg and the first try I've done is to dump this packets to a tmp file and open it use the av_open_inputfile ,but some time the problem is the Codec parameters can't found. so I'm hoping to organize the h264 stream and decode it use the ffmpeg .so How ?Attached:2012-03-21 09:22:37.171 MScope[3006:18f03] received data: <000001ba 66dbf7a3 840100a3 dbfeffff 04354f8b 000001e0 00128c80 0729b6fd e8e1fffc 00000001 09300000 000001e0 00aa8c00 03fffffc 00000001 419a1840 c20837cb ecc1177e e7ead1fc db167e27 a150bf97 dc4736f8 ce12d81f 42fc65ff 607a1f62 89e4f431 5ddfae4f 40fc2bec 5d096c7f 89e6bf0a f27b1077 93d03087 11ebacfc 39e86b1c 27ff2756 97bec73f 37a02370 d7b14b40 7d163f89 d0bd39f9 eb8b1fde 188cefa1 425c97ef 936b5cf5 b1fe7eb1 45f0e638 17382919 1f0c932f f0deab3a ed7ffcbd 3f929f09 735f939f 2e8be16e 7ad01ce3 3e1dbcb0>
2012-03-21 09:22:37.171 MScope[3006:18f03] 220
2012-03-21 09:22:37.202 MScope[3006:18f03] received data: <000001c0 005a8c80 0729b6fd ebcdfffc 1c416a02 d447004f ff16c1bc 2a0eb902 4c185085 04e660cb 3595856a 3eccb10a 761db750 3fb0171e 1c382a62 cf9ff10a ff37e750 55c16fad 22c1933f 03f00878 73521346 4c748898 9d9859a0 a573ada3>
2012-03-21 09:22:37.202 MScope[3006:18f03] 96
2012-03-21 09:22:37.211 MScope[3006:18f03] received data: <000001ba 66dbfc14 040100a3 dbfeffff 04354f8c 000001e0 00128c80 0729b6ff 0501fffc 00000001 09300000 000001e0 00e28c00 03fffffc 00000001 419a1880 c40833d5 a2f9bdfc bde3fac5 08f7ee33 ab447119 07fec5e5 d9fe5b17 0a704b8d 177de307 d7c64c4a cfb5a158 687c2bc4 ec5f327e e85c1872 502e4eef cdcb60df 1363a6e5 df2f27b9 386f746f 2c644bd2 a2c4f7b0 7ae6df7c bd8a4eec ff977df0 e6c0b58f 0b8ff0a7 2f7ae08f b3f4672d ecbe4f75 c37d8ebe 83e6e6bf f7ecc673 76055c57 998beb9b 6079797b c670e740 f87a2ff1 bec150b4 bb04df59 44a718ff 86265adf a12e07da 7ffe5e87 f268058a eac44f27 bf9281f3 f2f6389e b57cda2f d5a4e1cb fd6457f8 fe4d9e7e 6d82cbde f9e00000>
2012-03-21 09:22:37.212 MScope[3006:18f03] 276
2012-03-21 09:22:37.242 MScope[3006:17f03] received data: <000001c0 005a8c80 0729b6ff 07edfffc a83864c2 4e7d4e20 8ae819c6 03724270 7e5730d9 6648f9c8 b2e966d7 bc814c21 06306342 3c05ffe3 5840fcc2 2d2ae65b 1f231694 c8c8b7a2 0ad5080a 4fc3452d 332e9a30 1a3af1e0 b970ad62 a76927c4>
2012-03-21 09:22:37.242 MScope[3006:17f03] 96
2012-03-21 09:22:37.251 MScope[3006:18f03] received data: <000001ba 66dbfc84 840100a3 dbfeffff 04354f8d 000001e0 00128c80 0729b6ff 2121fffc 00000001 09300000 000001e0 00fa8c00 03fffffc 00000001 419a18c0 c608d7ff ffffffff e5f27fd5 5a2aa5f7 3556292a 6e945f5e 967c4757 89efd097 5e847847 d88545e8 7f97b053 75e8ee3b d02a03ec 5f825ec1 a07d80ab e5d0b0a7 7a02fdd8 b88e4d0b 35e2b928 7dc6785b 5c57a176 2158a9b9 ba17c9d0 a5ef61e2 7bdf1379 fac52f0b 7760f4eb 28dffe17 f761f5d8 be2388d1 ecf89eef c9c2f616 80ba12fd 963fbd1d 35797872 c541a025 c547f11d ec1e7e1b a7d7d9d9 cfc27b17 d88dcb7e 23bbf5c1 2632507c abaf572f 7ae4bf24 9579facb e18bd2c6 c2c3ced9 df10fff0 dfa3604b b1fd70d6 c0f5b2fc 56feaf11 d5af86f7 d765f372 76296f17 cf59c4e4 19f0b736 81632000>
2012-03-21 09:22:37.251 MScope[3006:18f03] 300
2012-03-21 09:22:37.282 MScope[3006:17f03] received data: <000001c0 005a8c80 0729b6ff 240dfffc 2e403ec4 2c07bc91 dea5816a fd1335b9 807cd133 4d0a12ac 876514ce 3883236b c0c17c9f 2b93ff26 d83827cc d30bf10a ca0262f5 09cad6ff 81fc2949 90de1ba6 11d98d2a 8dd5e80a e952f45e a4a0e711>
2012-03-21 09:22:37.282 MScope[3006:17f03] 96
2012-03-21 09:22:37.293 MScope[3006:17f03] received data: <000001ba 66dbfcf5 040100a3 dbfeffff 04354f8e 000001bc 0052f5ff 0024400e 484b0001 0c3aa503 2000ffff ffff4112 484b0000 00000000 00000000 00000000 00000024 1be00010 420e0000 60000160 0120111f ff001c20 92c0000c 430a0050 ff00fa03 00fa03ff 7c67884a 000001e0 00128c80 0729b6ff 3d41fffc 00000001 09100000 000001e0 001e8c00 03fffffc 00000001 6742800d 888b40b0 4b420000 0e100002 bf200800 000001e0 000e8c00 03fffffc 00000001 68ce3880 000001e0 253e8c00 03fffffc 00000001 65888008 0002e1f0 87e3e160 001021a1 e0002079 f5eaabd1 80def5ad ec1bc438 f10f7bbc 40904989 1c78adee f726e7dd a4dcfbbc 9b93bcf9 fff870a4 43cb65ed e5f97aff 08c7f510 3ce7c6de 3c3f72b2 f76f9cd1 fe3c3ff5 7103e5e7 3ebd7aae fdffffd4 5d6aafb7 d576f1f0 ffb8ac43 e99cf6f6 fd755d42 d84e2239 fff2c357 bd6b08e0 016317b0 91a8eb7a 18bec15f be000e13 b8cd2ed1 88a11360 250fd11b aa269986 2dffe034 9de244ca 1f4a2bf6 a03404c2 8aebc2cd bb012c7b 08cf5936 cd290fff 01a6ed52 fce1b482 ff6a58f7 3019ed40 4fabc400 0080b59a 5045138e 2394b709 5cfb905d 17771f4c ed199f0e 400021c6 6a934a0d edfbe012 5cb14bf0 06288cd2 dff7fe01 c3800877 0249cb92 6ca17482 1ffb02b8 bf314562 1e93d5e9 0226b833 bbeef4b9 c0e0409d c66977d8 8a1136f7 087e88dd 43e99852 4dfff684 ef122650 fa4105fe d8078128 a2a01b3a 229f9738 089c4a96 c49b5305 822612c5 b2529a5f f61144e3 88e52587 87f9f7a0 5d1f05d2 6cc4327f 7c3c30ff 0ef6b1ee 272da862 4f578092 c2eff5d9 67901b5a 3d40370a d561de23 7d7fd7fb e3168a50 5ebbca21 092c7800 1b046172 c0070995 3a84bd87 512fdfbc 62f18a0b b79742b1 86f863d1 0ae997ed 8bffff0d 0940abf5 30ea6ade 6f18b652 82f4de63 95e4ecb8 6c0001bb 419926c6 b00fb1f9 89849d59 bffaffd1 f1e11806 0170158f 6119ab7d b34a41bf fed0ddaa 5f9436b8 b7fed6b1 ee6023da 81e64f57 88001000 40213204 09d46693 7d88a3ac 5ee10fd3 0ba87d2b 0a49bffe b1a80854 dea31059 bb56201f a2351d89 c59ffeff 6c01711a a4d282e3 beff7de1 778a5f80 2484fa95 4e4d83cb 8f1034cb 96340f64 7f64d8a8 b7ad9651 712ec6b1 67ffbfd0 4ba7f00f 0fdcb540 05717065 7b5465b4 25e60c01 c7e2b86d a8ca7269 e00a1eaa ca98c1ef 60c6f885 ab1113ff d3afe21e aac1b2b2 dc9d7ffc 534cf3e6 3f15c36d 5653938f 000f0361 2ab4deb7 5b097f7e 7a000240 6b40cf05 de43d558 3655e5b9 3af19674 020bd93a 4dbba3b7 ef8d8895 5b87c403 805f913a 8cb26fb1 147589dc 21fa6175 0fa56149 2fffda13 bc49b285 d20827f6 c0783510 4402e744 51f2ed09 de24d942 eb887fec 0ae2f4ce 7310549e af481328 c3b79eff 0b9c0dd8 4e2618ee 5258785f 9f7a0ba2 e1f5f657 3277c648 23245c04 c83a92c4 9b530782 641d4962 4da9bf5b f807e10d c04ccc9c 62307fac 29a60001 8046932c 09820010 51505e80 01d0f556 54c60b7b 4513e216 a8446fff 4fefada2 412adcc3 956f1951 e7000081 c300014d 9121bf46 9d67e440 007022cf 9d8c0008 1452e998 1a47867e c2d45b16 f3626bf8 43e01b87 58003509 94764dbf 3e907092 79ae081d 31c4bb46 69e737dd 8b1ea663 9f9045bc d5e02801 616c9ba6 714f53f1 bfffa004 d05e5a18 d35d4600 01b0451b 2c0ac2f8 ec731444 9eaf61c0 3c21df00 041bba2e 4d9c2cd5 8d647806 001c191a f217aac8 bf6ebf26 0661e728 b3ad2c70 d6b801d0 8ab2d607 7567a0dc 18545ea1 3a9c24d3 ef3480d0 859e766e d89b7002 87ea32be cbc01e38 3b8904b6 85c20ab7 ea331800 20068064 9801f63f 3131a396 37dd84c0 e83aa118 6505d9e6 b2607710 7562f167 abd80098 e2ae6dc9 63acb7ff bcb00043 d2949eb4 2d059ff7 c806010f 0c2fa6c1 a946df28 843a4f7f fc068119 f17063a7 f9e96bac 960c44ce 2350b376 bc896424 4f57a775 00617aac 1f6eb2dc 8c683dac 8c82e729 887376b8 b436405c 9add43ae 1ede44b2 1227efd3 abf8059b 0474de09 7774ad25 8131c45d 5b16ba99 7ffbc1ab cc000300 8d2e5bf0 f8618760 c002c4ca 9c33af62 d2fadf80 0110fd46 55d97ec8 bea68d21 b7565455 e9c31aa0 65af0015 2d3ce021 456810b2 51944db3 fddeee9b 8b54196e 65fb65dc 07e38601 c001f1e8 632947b5 69082fff d81bb54f 9425b896 bfed6b1e a6066ad0 34a9eaf1 80008004 90527a04 09d44593 3d88a32c 4ee10fd3 1d482d2b 08497ffe f45f288b dbbe3dc9 154f31e8 8ea9afda 2a8200b8 8b47d287 c77bfefb 82ef15fe 0107f295 461ff1ad 4b09b3ee 64c26788 e3918de0 bbc57f80 41bca551 87fc3186 3d4b77f2 e977ff80 601c3db8 5e1d8e62 8893d5e0 521e8773 9ca729ea f000593b c49b28f6 e737f605 717a6739 88729eaf 48132883 b79deecb 9c49a8e0 263b1c86 3a0ea702 613d686a d07510d3 221e6870 1320a84a bcda983c 4120aa4b 126d4ccb 35da8dfc badfff00 c02e02b1 e8632945 b569082f ffde63d1 1d5375da 2fc1a811 ca4001f5 183f6d77 087e98ea 41695842 4bfff07b 70bc3b1c c5339eaf 0290f42b 9ce517cf 57acc838 37e1b78e dbec6594 e851312a 4cbffde3 0cd065f4 b38098ec 7208b41d 4e04c27a 50b6a0ea c4d03ff4 b7f0e002 1d4002c9 de24d947 b739bfb0 2b8bf239 ccc2f9ea f4813288 3b79deec b9c2d600 813a88b7 cf6228cb 3f7087e9 8ea41695 8424bfff 684ef34d 942eb9cf fdb01e09 441101f1 a7ffc5ce 02641509 579b5305 82641d89 54fa6972 f246c273 20677212 a342fcfb d0be5c3e b6c8e64e eb9f8e9a 5ba3b0c3 ffc39469 702e5d36 7d68ec13 e9537ffd 6a12c196 85fd7eb5 f7ffff7d f5f76d55 bffffeeb aad5557a ac2d80d7 6472c7ff 65eaf7ad 65e4ce44 4e6fd87c 03feb6a4 b07ee538 03678a66 d3c2adda 560ef825 919bd03f 6150cc6c a8b3f229 3d8e032c 6aa5fcc3 182ce001 00e18006 a7ec5187 6a65f6d2 7cf0fd38 4c3c81b9 a203cd47 dc5ef2cf b76badc4 e1b70631 5427809e 70add3da 573a5f08 b596b08e ae9ad931 6165c21f 99813f89 af0b609c 2990c1be 21ffaaac 1afd1715 34f05304 e13c0377 53d3ff8b e373bacf 1763b1b8 4f01d3f2 e2d47c6d f4338259 f6bb7615 71508fa3 b1560108 61fea0b7 c32c87f7 b8754cc9 5ae6b0ed 3322ac3c 21ff55fc 9c0ebf07 cd31ba9d 73778a3a 641b29d1 aa27c103 1a51fa81 4cd09e53 b47dbed9 f7fc6334 27b097d2 aeb4886b fc14c3b2 84f1e69d 2319adfa e32e33fe 3540c8a1 3c8ce75b fe0cd2de 7e67c0e9 77387d78 7ffea2c2 255307be cf9d5791 8ae3e1ff 797d34cb cbe6b6e5 545f01ff fd78a6f5 8baaa88f 52fc5582 e921ffff bd5755cd d7955c21 f080807e bd570ed1 a9c00080 de46a1a8 3c952d1c bf5dbffe 018075d5 753662b5 16773057 1f20ef34 2e9a7b65 dffe01f0 415860ce 9ea028b4 5e696823 9b3ffef2 c3e001f0 8781f698 5d0ca532 ca4669f6 45b68cac 8c879acf 58047991 d83bf4d3 eb460597 0dd82063 4ad7f00f ffeba517 7aaae76a 8b9daad4 b4135aa5 33972b8c ff77f01a 2196a9f7 a13c0084 c4b72067 ee45d6dd 84ece8ab 20896587 7a29684d 34fdcfb5 b45572c3 a3596756 3fffea01 d6ee1470 73f23c40 414c7976 28f9af2f 8b8310df d9096e32 d0c25dfc 7ffb9061 3a4119f9 66583fd4 a57b5ad0 2faad4b4 388db69e e6231fff f5870306 d68bc10d 7884883a 3774d25f f4c1dc83 d96881aa 6bdff0ff acd5e94f a3ac1c70 4f731594 e4419a7e 4a9d019b ffff960e b7a656aa f4c52994 d67e3047 8963414c 2a1b4234 fab9bb44 6bdfc3ff 8631dbc6 90439720 b987ffff eb2bfac7 9eb16412 3ffffcd5 5d5557a7 37ffff75 55d5757a a7ac38a7 ab091476 c0210843 0f99901d 8ed04273 fd6ee0a6 10d35a20 abaf126b 63df37b3 36ce3462 7379aad9 6efbf4ff fe001f8e 8657d1df 8d8eadf8 7951d85a a8dcb6d7 b9203b51 9ddea6e1 6296ba69 b9d8937a 2e4b15c5 d9f957a7 1f100fff d70e7890 0677c46a 2315fa73 41f538a8 7fb251ef e0e4c3d1 563c5a98 eb328853 30607ef4 3f81fd72 1e6ae3bf fff85ebd 00cd260e ea58a46f 9320d59a 4cc60a32 2e5e27f5 63080d95 9e843194 1fffebff> -
Improved thumbnail extraction from videos
21 janvier 2014, par Tommy NgI have been using FFmpeg to find the middle frame of a h264 video file, and extract the jpg thumbnail for use on a streaming portal. This is done automatically for each uploaded video.
Sometimes the frame happens to be a black frame or just semantically bad i.e. a background or blurry shot which doesn't relate well to the video content.
I wonder if I can use openCV or some other method/library to programmatically find better thumbnails through facial recognition or frame analysis.
-
A systematic approach to making Web Applications accessible
22 février 2012, par silviaWith the latest developments in HTML5 and the still fairly new ARIA (Accessible Rich Interface Applications) attributes introduced by the W3C WAI (Web Accessibility Initiative), browsers have now implemented many features that allow you to make your JavaScript-heavy Web applications accessible.
Since I began working on making a complex web application accessible just over a year ago, I discovered that there was no step-by-step guide to approaching the changes necessary for creating an accessible Web application. Therefore, many people believe that it is still hard, if not impossible, to make Web applications accessible. In fact, it can be approached systematically, as this article will describe.
This post is based on a talk that Alice Boxhall and I gave at the recent Linux.conf.au titled “Developing accessible Web apps – how hard can it be ?” (slides, video), which in turn was based on a Google Developer Day talk by Rachel Shearer (slides).
These talks, and this article, introduce a process that you can follow to make your Web applications accessible : each step will take you closer to having an application that can be accessed using a keyboard alone, and by users of screenreaders and other accessibility technology (AT).
The recommendations here only roughly conform to the requirements of WCAG (Web Content Accessibility Guidelines), which is the basis of legal accessibility requirements in many jurisdictions. The steps in this article may or may not be sufficient to meet a legal requirement. It is focused on the practical outcome of ensuring users with disabilities can use your Web application.
Step-by-step Approach
The steps to follow to make your Web apps accessible are as follows :
- Use native HTML tags wherever possible
- Make interactive elements keyboard accessible
- Provide extra markup for AT (accessibility technology)
If you are a total newcomer to accessibility, I highly recommend installing a screenreader and just trying to read/navigate some Web pages. On Windows you can install the free NVDA screenreader, on Mac you can activate the pre-installed VoiceOver screenreader, on Linux you can use Orca, and if you just want a browser plugin for Chrome try installing ChromeVox.
1. Use native HTML tags
As you implement your Web application with interactive controls, try to use as many native HTML tags as possible.
HTML5 provides a rich set of elements which can be used to both add functionality and provide semantic context to your page. HTML4 already included many useful interactive controls, like <a>, <button>, <input> and <select>, and semantic landmark elements like <h1>. HTML5 adds richer <input> controls, and a more sophisticated set of semantic markup elements like such as <time>, <progress>, <meter>, <nav>, <header>, <article> and <aside>. (Note : check browser support for browser support of the new tags).
Using as much of the rich HTML5 markup as possible means that you get all of the accessibility features which have been implemented in the browser for those elements, such as keyboard support, short-cut keys and accessibility metadata, for free. For generic tags you have to implement them completely from scratch.
What exactly do you miss out on when you use a generic tag such as <div> over a specific semantic one such as <button> ?
- Generic tags are not focusable. That means you cannot reach them through using the [tab] on the keyboard.
- You cannot activate them with the space bar or enter key or perform any other keyboard interaction that would be regarded as typical with such a control.
- Since the role that the control represents is not specified in code but is only exposed through your custom visual styling, screenreaders cannot express to their users what type of control it is, e.g. button or link.
- Neither can screenreaders add the control to the list of controls on the page that are of a certain type, e.g. to navigate to all headers of a certain level on the page.
- And finally you need to manually style the element in order for it to look distinctive compared to other elements on the page ; using a default control will allow the browser to provide the default style for the platform, which you can still override using CSS if you want.
Example :
Compare these two buttons. The first one is implemented using a <div> tag, the second one using a <button> tag. Try using a screenreader to experience the difference.
<style> .custombutton cursor : pointer ; border : 1px solid #000 ; background-color : #F6F6F6 ; display : inline-block ; padding : 2px 5px ; </style> <div class="custombutton" onclick="alert(’sent !’)"> Send </div>
<button onclick="alert(’sent !’)"> Send </button>
2. Make interactive elements keyboard accessible
Many sophisticated web applications have some interactive controls that just have no appropriate HTML tag equivalent. In this case, you will have had to build an interactive element with JavaScript and <div> and/or <span> tags and lots of custom styling. The good news is, it’s possible to make even these custom controls accessible, and as a side benefit you will also make your application smoother to use for power users.
The first thing you can do to test usability of your control, or your Web app, is to unplug the mouse and try to use only the [TAB] and [ENTER] keys to interact with your application.
Try the following :
- Can you reach all interactive elements with [TAB] ?
- Can you activate interactive elements with [ENTER] (or [SPACE]) ?
- Are the elements in the right tab order ?
- After interaction : is the right element in focus ?
- Is there a keyboard shortcut that activates the element (accesskey) ?
No ? Let’s fix it.
2.1. Reaching interactive elements
If you have an element on your page that cannot be reached with [TAB], put a @tabindex attribute on it.
Example :
Here we have a <span> tag that works as a link (don’t do this – it’s just a simple example). The first one cannot be reached using [TAB] but the second one has a tabindex and is thus part of the tab order of the HTML page.
(Note : since we experiment lots with the tabindex in this article, to avoid confusion, click on some text in this paragraph and then hit the [TAB] key to see where it goes next. The click will set your keyboard focus in the DOM.)
Click
<style> .customlink text-decoration : underline ; cursor : pointer ; </style> <span class="customlink" onclick="alert(’activated !’)"> Click </span>
Click <style> .customlink text-decoration : underline ; cursor : pointer ; </style> <span class="customlink" onclick="alert(’activated !’)" tabindex="0"> Click </span>
You set @tabindex=0 to add an element into the native tab order of the page, which is the DOM order.
2.2. Activating interactive elements
Next, you typically want to be able to use the [ENTER] and [SPACE] keys to activate your custom control. To do so, you will need to implement an onkeydown event handler. Note that the keyCode for [ENTER] is 13 and for [SPACE] is 32.
Example :
Let’s add this functionality to the <span> tag from before. Try tabbing to it and hit the [ENTER] or [SPACE] key.
Click <span class="customlink" onclick="alert(’activated !’)" tabindex="0"> Click </span>
<script><br />
function handlekey(event) {<br />
var target = event.target || event.srcElement;<br />
if (event.keyCode == 13 || event.keyCode == 32) { target.onclick(); }<br />
}<br />
</script>
Click<span class="customlink" onclick="alert(’activated !’)" tabindex="0" onkeydown="handlekey(event) ;"> Click </span> <script> function handlekey(event) var target = event.target || event.srcElement ; if (event.keyCode == 13 || event.keyCode == 32) target.onclick() ; </script>
Note that there are some controls that might need support for keys other than [tab] or [enter] to be able to use them from the keyboard alone, for example a custom list box, menu or slider should respond to arrow keys.
2.3. Elements in the right tab order
Have you tried tabbing to all the elements on your page that you care about ? If so, check if the order of tab stops seems right. The default order is given by the order in which interactive elements appear in the DOM. For example, if your page’s code has a right column that is coded before the main article, then the links in the right column will receive tab focus first before the links in the main article.
You could change this by re-ordering your DOM, but oftentimes this is not possible. So, instead give the elements that should be the first ones to receive tab focus a positive @tabindex. The tab access will start at the smallest non-zero @tabindex value. If multiple elements share the same @tabindex value, these controls receive tab focus in DOM order. After that, interactive elements and those with @tabindex=0 will receive tab focus in DOM order.
Example :
The one thing that always annoys me the most is if the tab order in forms that I am supposed to fill in is illogical. Here is an example where the first and last name are separated by the address because they are in a table. We could fix it by moving to a <div> based layout, but let’s use @tabindex to demonstrate the change.
Firstname :
Address :
Lastname :
City :
<table class="customtabs"> <tr> <td>Firstname : <input type="text" id="firstname"> </td> <td>Address : <input type="text" id="address"> </td> </tr> <tr> <td>Lastname : <input type="text" id="lastname"> </td> <td>City : <input type="text" id="city"> </td> </tr> </table>
Click here to test this form,
then [TAB] :Firstname :
Address :
Lastname :
City :
<table class="customtabs"> <tr> <td>Firstname : <input type="text" id="firstname" tabindex="10"> </td> <td>Address : <input type="text" id="address" tabindex="30"> </td> </tr> <tr> <td>Lastname : <input type="text" id="lastname" tabindex="20"> </td> <td>City : <input type="text" id="city" tabindex="40"> </td> </tr> </table>
Be very careful with using non-zero tabindex values. Since they change the tab order on the page, you may get side effects that you might not have intended, such as having to give other elements on the page a non-zero tabindex value to avoid skipping too many other elements as I would need to do here.
2.4. Focus on the right element
Some of the controls that you create may be rather complex and open elements on the page that were previously hidden. This is particularly the case for drop-downs, pop-ups, and menus in general. Oftentimes the hidden element is not defined in the DOM right after the interactive control, such that a [TAB] will not put your keyboard focus on the next element that you are interacting with.
The solution is to manage your keyboard focus from JavaScript using the .focus() method.
Example :
Here is a menu that is declared ahead of the menu button. If you tab onto the button and hit enter, the menu is revealed. But your tab focus is still on the menu button, so your next [TAB] will take you somewhere else. We fix it by setting the focus on the first menu item after opening the menu.
<script><br />
function displayMenu(value) {<br />
document.getElementById("custommenu").style.display=value;<br />
}<br />
</script><div id="custommenu" style="display:none ;"> <button id="item1" onclick="displayMenu(’none’) ;">Menu item1</button> <button id="item2" onclick="displayMenu(’none’) ;">Menu item2</button> </div> <button onclick="displayMenu(’block’) ;">Menu</button> <script> function displayMenu(value) document.getElementById("custommenu").style.display=value ; </script>
<script><br />
function displayMenu2(value) {<br />
document.getElementById("custommenu2").style.display=value;<br />
document.getElementById("item1").focus();<br />
}<br />
</script><div id="custommenu" style="display:none ;"> <button id="item1" onclick="displayMenu(’none’) ;">Menu item1</button> <button id="item2" onclick="displayMenu(’none’) ;">Menu item2</button> </div> <button onclick="displayMenu(’block’) ;">Menu</button> <script> function displayMenu(value) document.getElementById("custommenu").style.display=value ; document.getElementById("item1").focus() ; </script>
You will notice that there are still some things you can improve on here. For example, after you close the menu again with one of the menu items, the focus does not move back onto the menu button.
Also, after opening the menu, you may prefer not to move the focus onto the first menu item but rather just onto the menu <div>. You can do so by giving that div a @tabindex and then calling .focus() on it. If you do not want to make the div part of the normal tabbing order, just give it a @tabindex=-1 value. This will allow your div to receive focus from script, but be exempt from accidental tabbing onto (though usually you just want to use @tabindex=0).
Bonus : If you want to help keyboard users even more, you can also put outlines on the element that is currently in focus using CSS”s outline property. If you want to avoid the outlines for mouse users, you can dynamically add a class that removes the outline in mouseover events but leaves it for :focus.
2.5. Provide sensible keyboard shortcuts
At this stage your application is actually keyboard accessible. Congratulations !
However, it’s still not very efficient : like power-users, screenreader users love keyboard shortcuts : can you imagine if you were forced to tab through an entire page, or navigate back to a menu tree at the top of the page, to reach each control you were interested in ? And, obviously, anything which makes navigating the app via the keyboard more efficient for screenreader users will benefit all power users as well, like the ubiquitous keyboard shortcuts for cut, copy and paste.
HTML4 introduced so-called accesskeys for this. In HTML5 @accesskey is now allowed on all elements.
The @accesskey attribute takes the value of a keyboard key (e.g. @accesskey="x") and is activated through platform- and browser-specific activation keys. For example, on the Mac it’s generally the [Ctrl] key, in IE it’ the [Alt] key, in Firefox on Windows [Shift]-[Alt], and in Opera on Windows [Shift]-[ESC]. You press the activation key and the accesskey together which either activates or focuses the element with the @accesskey attribute.
Example :
<script><br />
var button = document.getElementById('accessbutton');<br />
if (button.accessKeyLabel) {<br />
button.innerHTML += ' (' + button.accessKeyLabel + ')';<br />
}<br />
</script><button id="accessbutton" onclick="alert(’sent !’)" accesskey="e"> Send </button> <script> var button = document.getElementById(’accessbutton’) ; if (button.accessKeyLabel) button.innerHTML += ’ (’ + button.accessKeyLabel + ’)’ ; </script>
Now, the idea behind this is clever, but the execution is pretty poor. Firstly, the different activation keys between different platforms and browsers make it really hard for people to get used to the accesskeys. Secondly, the key combinations can conflict with browser and screenreader shortcut keys, the first of which will render browser shortcuts unusable and the second will effectively remove the accesskeys.
In the end it is up to the Web application developer whether to use the accesskey attribute or whether to implement explicit shortcut keys for the application through key event handlers on the window object. In either case, make sure to provide a help list for your shortcut keys.
Also note that a page with a really good hierarchical heading layout and use of ARIA landmarks can help to eliminate the need for accesskeys to jump around the page, since there are typically default navigations available in screen readers to jump directly to headings, hyperlinks, and ARIA landmarks.
3. Provide markup for AT
Having made the application keyboard accessible also has advantages for screenreaders, since they can now reach the controls individually and activate them. So, next we will use a screenreader and close our eyes to find out where we only provide visual cues to understand the necessary interaction.
Here are some of the issues to consider :
- Role may need to get identified
- States may need to be kept track of
- Properties may need to be made explicit
- Labels may need to be provided for elements
This is where the W3C’s ARIA (Accessible Rich Internet Applications) standard comes in. ARIA attributes provide semantic information to screen readers and other AT that is otherwise conveyed only visually.
Note that using ARIA does not automatically implement the standard widget behavior – you’ll still need to add focus management, keyboard navigation, and change aria attribute values in script.
3.1. ARIA roles
After implementing a custom interactive widget, you need to add a @role attribute to indicate what type of controls it is, e.g. that it is playing the role of a standard tag such as a button.
Example :
This menu button is implemented as a <div>, but with a role of “button” it is announced as a button by a screenreader.
<div tabindex="0" role="button">Menu</div>
ARIA roles also describe composite controls that do not have a native HTML equivalent.
Example :
This menu with menu items is implemented as a set of <div> tags, but with a role of “menu” and “menuitem” items.
<div role="menu"> <div tabindex="0" role="menuitem">Cut</div> <div tabindex="0" role="menuitem">Copy</div> <div tabindex="0" role="menuitem">Paste</div> </div>
3.2. ARIA states
Some interactive controls represent different states, e.g. a checkbox can be checked or unchecked, or a menu can be expanded or collapsed.
Example :
The following menu has states on the menu items, which are here not just used to give an aural indication through the screenreader, but also a visual one through CSS.
<style> .custombutton[aria-checked=true]:before content : "\2713 " ; </style> <div role="menu"> <div tabindex="0" role="menuitem" aria-checked="true">Left</div> <div tabindex="0" role="menuitem" aria-checked="false">Center</div> <div tabindex="0" role="menuitem" aria-checked="false">Right</div> </div>
3.3. ARIA properties
Some of the functionality of interactive controls cannot be captured by the role attribute alone. We have ARIA properties to add features that the screenreader needs to announce, such as aria-label, aria-haspopup, aria-activedescendant, or aria-live.
Example :
The following drop-down menu uses aria-haspopup to tell the screenreader that there is a popup hidden behind the menu button together with an ARIA state of aria-expanded to track whether it’s open or closed.
<script><br />
var button = document.getElementById("button");<br />
var menu = document.getElementById("menu");<br />
var items = document.getElementsByClassName("menuitem");<br />
var focused = 0;<br />
function showMenu(evt) {<br />
evt.stopPropagation();<br />
menu.style.visibility = 'visible';<br />
button.setAttribute('aria-expanded','true');<br />
focused = getSelected();<br />
items[focused].focus();<br />
}<br />
function hideMenu(evt) {<br />
evt.stopPropagation();<br />
menu.style.visibility = 'hidden';<br />
button.setAttribute('aria-expanded','false');<br />
button.focus();<br />
}<br />
function getSelected() {<br />
for (var i=0; i < items.length; i++) {<br />
if (items[i].getAttribute('aria-checked') == 'true') {<br />
return i;<br />
}<br />
}<br />
}<br />
function setSelected(elem) {<br />
var curSelected = getSelected();<br />
items[curSelected].setAttribute('aria-checked', 'false');<br />
elem.setAttribute('aria-checked', 'true');<br />
}<br />
function selectItem(evt) {<br />
setSelected(evt.target);<br />
hideMenu(evt);<br />
}<br />
function getPrevItem(index) {<br />
var prev = index - 1;<br />
if (prev < 0) {<br />
prev = items.length - 1;<br />
}<br />
return prev;<br />
}<br />
function getNextItem(index) {<br />
var next = index + 1;<br />
if (next == items.length) {<br />
next = 0;<br />
}<br />
return next;<br />
}<br />
function handleButtonKeys(evt) {<br />
evt.stopPropagation();<br />
var key = evt.keyCode;<br />
switch(key) {<br />
case (13): /* ENTER */<br />
case (32): /* SPACE */<br />
showMenu(evt);<br />
default:<br />
}<br />
}<br />
function handleMenuKeys(evt) {<br />
evt.stopPropagation();<br />
var key = evt.keyCode;<br />
switch(key) {<br />
case (38): /* UP */<br />
focused = getPrevItem(focused);<br />
items[focused].focus();<br />
break;<br />
case (40): /* DOWN */<br />
focused = getNextItem(focused);<br />
items[focused].focus();<br />
break;<br />
case (13): /* ENTER */<br />
case (32): /* SPACE */<br />
setSelected(evt.target);<br />
hideMenu(evt);<br />
break;<br />
case (27): /* ESC */<br />
hideMenu(evt);<br />
break;<br />
default:<br />
}<br />
}<br />
button.addEventListener('click', showMenu, false);<br />
button.addEventListener('keydown', handleButtonKeys, false);<br />
for (var i = 0; i < items.length; i++) {<br />
items[i].addEventListener('click', selectItem, false);<br />
items[i].addEventListener('keydown', handleMenuKeys, false);<br />
}<br />
</script><div class="custombutton" id="button" tabindex="0" role="button" aria-expanded="false" aria-haspopup="true"> <span>Justify</span> </div> <div role="menu" class="menu" id="menu" style="display : none ;"> <div tabindex="0" role="menuitem" class="menuitem" aria-checked="true"> Left </div> <div tabindex="0" role="menuitem" class="menuitem" aria-checked="false"> Center </div> <div tabindex="0" role="menuitem" class="menuitem" aria-checked="false"> Right </div> </div> [CSS and JavaScript for example omitted]
3.4. Labelling
The main issue that people know about accessibility seems to be that they have to put alt text onto images. This is only one means to provide labels to screenreaders for page content. Labels are short informative pieces of text that provide a name to a control.
There are actually several ways of providing labels for controls :
- on img elements use @alt
- on input elements use the label element
- use @aria-labelledby if there is another element that contains the label
- use @title if you also want a label to be used as a tooltip
- otherwise use @aria-label
I’ll provide examples for the first two use cases - the other use cases are simple to deduce.
Example :
The following two images show the rough concept for providing alt text for images : images that provide information should be transcribed, images that are just decorative should receive an empty @alt attribute.
Image by Noah Sussman<img src="texture.jpg" alt=""> <img src="lolcat.jpg" alt="shocked lolcat titled ’HTML cannot do that !"> <img src="texture.jpg" alt="">
When marking up decorative images with an empty @alt attribute, the image is actually completely removed from the accessibility tree and does not confuse the blind user. This is a desired effect, so do remember to mark up all your images with @alt attributes, even those that don’t contain anything of interest to AT.
Example :
In the example form above in Section 2.3, when tabbing directly on the input elements, the screen reader will only say "edit text" without announcing what meaning that text has. That’s not very useful. So let’s introduce a label element for the input elements. We’ll also add checkboxes with a label.
<label>Doctor title :</label> <input type="checkbox" id="doctor"/> <label>Firstname :</label> <input type="text" id="firstname2"/>
<label for="lastname2">Lastname :</label>
<input type="text" id="lastname2"/><label>Address :
<input type="text" id="address2">
</label>
<label for="city2">City :
<input type="text" id="city2">
</label>
<label for="remember">Remember me :</label>
<input type="checkbox" id="remember">In this example we use several different approaches to show what a different it makes to use the <label> element to mark up input boxes.
The first two fields just have a <label> element next to a <input> element. When using a screenreader you will not notice a difference between this and not using the <label> element because there is no connection between the <label> and the <input> element.
In the third field we use the @for attribute to create that link. Now the input field isn’t just announced as "edit text", but rather as "Lastname edit text", which is much more useful. Also, the screenreader can now skip the labels and get straight on the input element.
In the fourth and fifth field we actually encapsulate the <input> element inside the <label> element, thus avoiding the need for a @for attribute, though it doesn’t hurt to explicity add it.
Finally we look at the checkbox. By including a referenced <label> element with the checkbox, we change the screenreaders announcement from just "checkbox not checked" to "Remember me checkbox not checked". Also notice that the click target now includes the label, making the checkbox not only more usable to screenreaders, but also for mouse users.
4. Conclusions
This article introduced a process that you can follow to make your Web applications accessible. As you do that, you will noticed that there are other things that you may need to do in order to give the best experience to a power user on a keyboard, a blind user using a screenreader, or a vision-impaired user using a screen magnifier. But once you’ve made a start, you will notice that it’s not all black magic and a lot can be achieved with just a little markup.
You will find more markup in the WAI ARIA specification and many more resources at Mozilla’s ARIA portal. Now go and change the world !
Many thanks to Alice Boxhall and Dominic Mazzoni for their proof-reading and suggested changes that really helped improve the article !