It is allowed to use an image as the content of a link, as long as the image has a useful and descriptive alt text.
Ref. criteria for succes 2.4.4, 2.4.9 en 4.1.2
 |
| Rejoice! |
Tuesday, February 25, 2014
Accessibility - Using images as a link conforming to Dutch webrichtlijnen overheid
As I always forget this, here is a micro-blog-post about this requirement for the Dutch Govermental organisations. Governmental sites need to comply with the 'Webrichtlijnen overheid versie 2'.
It is allowed to use an image as the content of a link, as long as the image has a useful and descriptive alt text.
Ref. criteria for succes 2.4.4, 2.4.9 en 4.1.2
It is allowed to use an image as the content of a link, as long as the image has a useful and descriptive alt text.
Ref. criteria for succes 2.4.4, 2.4.9 en 4.1.2
Thursday, February 6, 2014
Drupal - Accessibility: ways of adding language attributes to parts of your text that differ from the main page language
Here I show two ways how to achieve this, (that is adding the attributes to the tags, not the tuna-sandwich part).
Case 1 in Drupal 6 wysiwyg with Tinymce, and Case 2 in Drupal 7 with CKEditor. Goal is to select a part of the html, and add a language attribute. Or to the containing tag or to add a span tag...
<tag>Lorem ipsum and so forth</tag>
should become
<tag lang="en">Lorem ipsum and so forth</tag>
CASE 1 Drupal 6
D6 site, with the WYSIWYG module using tinymce
1. Add html attributes button to your RTE
1.1 Go to Administer > Site configuration > wysiwyg profiles
1.2 edit any of the profiles where you want the users to be able to add the language attribute
admin/settings/wysiwyg/profile/1/edit
1.3 Open 'Buttons and plugins'
1.4 Check 'HTML attributes'1.5 Save
Result: How to add a language identifier
In your browser you can now find a new button
a. Select part of a text and click this button
This opens up a popup screen where you can add attributes
b. Behind language add the language identifier for the language usedf.i. en (english), nl (dutch) etc.
See also http://www.w3schools.com/tags/ref_language_codes.asp
c. Click insert
And the language identifier is added to the tag containing the textpart.
NB!
If you add an identifier to a part where a mother tag already contains the same language identifier, the identifier is not added. This seems logical because there is no need for this identifier at all.
Problem: adding lang attribute to inline tags
You cannot add attributes to inline tags like <span>
This is really annoying cause you have lots of cases where the other language words or sentences are inline with the other text. Like when I tell you the Dutch word for annoying is irritant.
Solution: use <em>
NB!
a. First make the text part italic!
b. Then select part of the inside italic text, not all, and add the language identifier.
c. Save
If you select the whole italic part (including the em tags), the system will find the nearest containing tag and add the language identifier to that one.
d. To avoid the other language being shown as italic, you can target this em element with the language selector in the css.
http://www.w3schools.com/cssref/sel_lang.asp
So like when you main language identifier is english
em:lang(nl),em:lang(fr), em:lang(ge)
font-style:normal;
}
NB!
Adding the em:lang(en) in the above css would change all em to normal, because the language selector simply looks for any language identification, may it be in the tag itselve, or in the header of the document like <html lang="en" dir="ltr" xml:lang="en" xmlns="http://www.w3.org/1999/xhtml">
<em lang="zh-Hant">希望對您有所助益<em>
PROBLEM!
There is a major problem in Drupal concerning these attributes. From the accessiblity viewpoint, it should be very simple to add a language attribute to every element. But I have to figure out yet how to add a language attribute to a field like the title. (Or the resulting display of this in a nodereference rendering)There are two language layers here you have to consider: The field language, which simply identifies in which languagepart of the site you want this field to show up, so in case of content translation this is the context language of the container entities, in case of field translation it is the [lang] part of the field.
For instamce, Being Dutch have nodes with partly Dutch and English titles: "Presentatie resultaten onderzoek 'Designed to Last' op 8 oktober 2014".
Trying to convince my governmental organisations to change the titles of their reports to solid Dutch does not work, so I have to deal with this. The result should be
<h1>Presentatie resultaten onderzoek <span lang="en" xml:lang="en">'Designed to Last'</span> op 8 oktober 2014</h1>
I solved it using a jquery on the specific nodes with these kinds of titles, but thats rather an unsatisfying solution.
CASE II : Drupal 7
So, I figured out how to do this in Drupal 7 with CKEditor. There is a CKEditor plugin you can install and download
Of course, because why should life be easy, there are some irritating bugs or features or whatever....
0. Plugin
You can download the plugin from here
https://github.com/fredck/CKEditor-Languages-Plugin
In the example hereunder my module path is
/sites/all/modules/contrib/ckeditor
and I've installed the ckeditor itself in
/sites/all/modules/contrib/ckeditor/ckeditor
1. Now make a folder 'languages' in
/sites/all/modules/contrib/ckeditor/ckeditor/plugins
2. put plugin.js and icon.png in this folder
/sites/all/modules/contrib/ckeditor/ckeditor/plugins/languages
3. open ckeditor.config.js in the root of your module and add these lines
config.extraPlugins = 'languages';
// The languages you want to support (code:name).
config.language_list = [ 'de:German', 'fr:French', 'es:Spanish', 'it:Italian', 'en:English' ];
NB! This is different from the installation instructions on GIThub.
4. Clear your Drupal cache AND clear your browser cache
(the ckeditor does not clear its javascript files on the normal Drupal cache clear)
5. Go to your CKEditor settings and add the languages button to your editor
(In an older version the visual UI did not work, but the manual did. Now this seems ok)
6. Content filters
You'd probably might have to change you content filters to allow for these attributes, but apart from that it should work. I had to add
p h1 h2 h3 h4 em span [*]
under the extra allowed content in the ckeditor setting for my filtered and full html
(/admin/config/content/ckeditor/edit/Filtered)
For more infor on this see http://docs.ckeditor.com/#!/guide/dev_allowed_content_rules
7. Rejoice in many languages
And yes, ganz lustig, it works
6. Content filters
You'd probably might have to change you content filters to allow for these attributes, but apart from that it should work. I had to add
p h1 h2 h3 h4 em span [*]
under the extra allowed content in the ckeditor setting for my filtered and full html
(/admin/config/content/ckeditor/edit/Filtered)
For more infor on this see http://docs.ckeditor.com/#!/guide/dev_allowed_content_rules
7. Rejoice in many languages
And yes, ganz lustig, it works
And yes, <span dir="ltr" lang="de" xml:lang="de">ganz lustig</span>, it works
Tuesday, February 4, 2014
Make two divs equal height with jquery (in Drupal)
One problem I often face is that I have two divs, a content div and next to it another div with a menu, or links to related content or whatever. And I want both divs, f.i. #content and #rightbar, to be equal height, but they are added loosely to the html bacause the html needs to be responsive. Sometimes you can get it working with css, but lots of time I get lost.
One solution is to simply compare the two and make them equal height with a javascript/jQuery function.
One solution is to simply compare the two and make them equal height with a javascript/jQuery function.
function equalHeight(one,two) {
var tallest = 0;
tallest=one.height();
if (tallest < two.height()) {
tallest=two.height();
}
one.height(tallest);
two.height(tallest);
}
Call this function in a document ready like so
(function ($) {
// drupal jquery wrapper
// drupal jquery wrapper
$(document).ready(function() {
equalHeight($("#content"),$("#rightbar"));
});
function equalHeight(one,two) {
var tallest = 0;
tallest=one.height();
if (tallest < two.height()) {
tallest=two.height();
}
one.height(tallest);
two.height(tallest);
}
// emdof drupal jquery wrapper
}(jQuery));
Monday, February 3, 2014
Lost books of the Bible: The book of Metatheria
There must be a lost biblebook which explains why all marsupials went straight to Australia after Noahs Ark stranded. 'Bye Noah, thanks for saving us!' And none of them decided to stop somewhere halfway in Afghanistan or China.
Well then, except for the opossum and the shrew opossum which went to respectively North and South America, and some lazy marsupials which, crossing Indonesia, decided to take a break and simply stayed there.
And they thus spoke to them, saying: 'Ah, don't worry, we'll cach up later....'. But that's all explained in this lost Bible book: 1 Metatheria 2:7
Well then, except for the opossum and the shrew opossum which went to respectively North and South America, and some lazy marsupials which, crossing Indonesia, decided to take a break and simply stayed there.
And they thus spoke to them, saying: 'Ah, don't worry, we'll cach up later....'. But that's all explained in this lost Bible book: 1 Metatheria 2:7
Saturday, January 25, 2014
Life and Death questions: Where to write the copyright in an image tag? In the Alt or in the Title attribute?
One of the important questions in my life is where to write the copyright statement in an Image tag. It's sometimes keeps me awake at night. It is one of those daunting questions which are not answered by one google query. For lots of use cases adding the copyright statement as a caption under the image is not an option.
ALT
The alt attribute should contain a description, in 150 characters or fewer, preferably a description in the context of the embedding page, of the visual content of the image. This is the part that mr. Google indexes. So it is the SEO part of the image as well as the visually impaired part, targeted at screenreaders and the like.
TITLE
The title contains the text that appears in the tooltip when you move your mouse over the image. It should contain additional info, like if the image is linked, where the link will lead you.
The Answer: The Title attribute
As the copyright is not a visual description of the image, you should therefore add it to the title attribute. This is also suggested by w3c.
But
But on the other hand, as you probably would like to buzz the photographers name around on the internet, and would like the search engines to find all the images belonging to a certain copyright holder, the alt attribute is also used for the copyright statement by lots of sites. The alt text should never begin with the copyright statement, but it is used a lot.
I do not know if there are any accessibility rules targeting the credit statement specifically for this matter.
Reading all information I suppose that from the viewpoint of accessibility it is a bad solution, but from the viewpoint of the search engines, it is a good solution.
ALT
The alt attribute should contain a description, in 150 characters or fewer, preferably a description in the context of the embedding page, of the visual content of the image. This is the part that mr. Google indexes. So it is the SEO part of the image as well as the visually impaired part, targeted at screenreaders and the like.
TITLE
The title contains the text that appears in the tooltip when you move your mouse over the image. It should contain additional info, like if the image is linked, where the link will lead you.
The Answer: The Title attribute
As the copyright is not a visual description of the image, you should therefore add it to the title attribute. This is also suggested by w3c.
But
But on the other hand, as you probably would like to buzz the photographers name around on the internet, and would like the search engines to find all the images belonging to a certain copyright holder, the alt attribute is also used for the copyright statement by lots of sites. The alt text should never begin with the copyright statement, but it is used a lot.
I do not know if there are any accessibility rules targeting the credit statement specifically for this matter.
Reading all information I suppose that from the viewpoint of accessibility it is a bad solution, but from the viewpoint of the search engines, it is a good solution.
Friday, January 24, 2014
Drupal 7 - specifying different output per role type in a template
Lot's of time I want content or links hidden for unauthenticated users but shown to the site administrators or other user roles. As I always forget how I do it, and then search in old code or ask my old friend mister Google, here's a little blog about how to:
In the template, for instance a field template for a field in a view, add this code.
For larger sites solution you should define these things using permissions, otherwise the site will in time become unmaintainable. Adding a permission to another role might then mean changing twenty template files or so.
Because setting up the normal permissions may become very complex, you can also add custom permissions with this module https://drupal.org/project/config_perms and use them in your template file for this kind of functionality.
In the template, for instance a field template for a field in a view, add this code.
// load the global user objectglobal $user;
// Check if user has (f.i.) the 'administrator' or 'contributor' role.
if (in_array('administrator', $user->roles)||in_array('contributor', $user->roles)) { // do something
} else { // do something else}
For larger sites solution you should define these things using permissions, otherwise the site will in time become unmaintainable. Adding a permission to another role might then mean changing twenty template files or so.
// user_access default takes the current logged in user as user object
if (user_access('permission x')) {
// do something} else {
// do something else }
Because setting up the normal permissions may become very complex, you can also add custom permissions with this module https://drupal.org/project/config_perms and use them in your template file for this kind of functionality.
Monday, December 2, 2013
National Library of the Netherlands - Migrating multilingual xHTML from a shoe-box to Drupal 7
 |
| Feynman diagrams |
(I have to find some apology for studying philosopy lateron, so any suggestions are welcome....)
Hail Laziness
Laziness is one of the least respected human inclinations. If there where no lazy people, no one would have invented the car, the combine, the phone et cetera. We would all be working our asses off all day in the fields, pushing little grains out of their stalks one by one. Books would have no indexes. Skyscrapers no elevators. Chairs no legs.
Royal Library of the Netherlands
One fine day (early 2012) we got like the following request from the Royal Library.
On the left we've got twenty shoeboxes of HTML, and on the right we have a brand new core structure for the website in Drupal 7: Contenttypes, Display Suite, Views and all.
Could you please import the information from the shoeboxes into the Drupal 7 system. Thankyouverymuch and Yesterday would be fine.
Being Lazy we simply said: Yes, of course we can. There is nothing we can't do.
And then imagine the soundtrack of Jaws on the background........
Delusions of simplicity
We said so because the concept in itself is very simple.
Here we have content A, B and C. In booklet X.
There, on the other side, is a new booklet Y.
Now copy A, B and C to booklet Y.
X( A B C ) --> Y( A B C )
What the hell were you thinking!
The source being ante-diluvian xHTML, more or less templated, from which we had to sift images, downloads and all other digital objects, parse all content from all these different structured pages, and then load and upload everything in the totally different structured Drupal 7 system.
 |
| Book of Hours of Simon de Varie. Paris, 1455; Tours, c. 1455. Vellum, 99 leaves, 116 x 85 mm. - 74 G 37a, fol. 1v-2r |
Oh Yeah, and did I mention the multilingual part? English and Dutch.
So it's a project with a big red rubber stamped warning on the cover:
Send project manager to
high altitude trainingcamp
before start!
Or, stated differently, in common ICT jargon: Blood, Sweat and Tears ahead.
Analysis: Dance like a butterfly...
The approach we used was the equivalent of dance like a butterfly and sting like a bee in webdevelopment. There is no way to oversee all problems in this kind of large projects concerning conversions between two totally different systems. In the quotation we made, which needed to be fixed price, we tried to include some bleeding control, but we knew beforehand that we were entering the Swamp part of our Portfolio.
It proved for instance especially difficult to emulate the maintenance features in the old system, which was an xml based editor. There was no way we could migrate these features to the new D7 setup. We were down to analysing every feature and approach it from a totally different angle in D7.
Another unexpected tricky part was recalculating all internal links in the site. We had to iterate all pages aproximately twenty times before we had all link types covered. Some linkit, some entityreferences, some link fields, et cetera.
Don't get me started...
For the sake of your mental health I will not elaborate on the technical details, anyone interested can contact me directly, but it's a lot like this
$filename2=createfilenameforimage($filenamearr);
$file2 = file_save_data($image2, 'public://'.$filename2,FILE_EXISTS_RENAME);
$field_collection_item->field_afbeelding=array(LANGUAGE_NONE => array('1' => (array)$file2));
$field_collection_item->field_alttekst[LANGUAGE_NONE][0]['value'] = $animageobject->alt;
$field_collection_item->field_titletekst[LANGUAGE_NONE][0]['value'] = $animageobject->title;
and than for days on end....
(And as for the bleeding part: Whoever thought up the idea of littering PHP code with all these dollar signs?)
5% inspiration, 99% iteration
I think we did about ten migrations. And after every migration the Royal Library checked the new site and discovered some new features or parts that weren't specified but certainly needed to be migrated as well. The Math was never right!
Never again!
And when you are finaly finished, and the site is migrated and the Royal Library is happy, the first three days you say to yourself: Never again. Behind every mountain there was another mountain, behind every tree there was a madman with an axe, behind every solution there appeared a brand new grinning unexpected problem produced by the very same solution, with five other problems stacked up his sleeve.
But on the fourth day you realise how much fun we had, how much we learnt about the internal workings of Drupal.
Geek sucks
I sometimes mind the Geeky part of my work, days of trying to get a certain piece of code right, minimal pixel adjustment feuds with the designers, that stuff. But when the subject matter itself is something like the Royal Library content, or digital heritage projects in general, I might just possibly be able to live with that.
http://www.kb.nl/en
Subscribe to:
Posts (Atom)