http://www.w3.org/TR/wai-aria-practices/
Created attachment 12869 [details] [review] Bug 8712 - Added title to the search box
Created attachment 12871 [details] [review] Bug 8712 1) Added labels to Search history and x links in the top frame 2) Changed search results message from <strong> to <h3> 3) Added the 'alt="cover image"' message to those entries that have cover images
Created attachment 12891 [details] [review] [SIGNED-OFF] Bug 8712 - We should use WAI-ARIA guidelines to help with accessibility Added title to the search box Signed-off-by: Owen Leonard <oleonard@myacpl.org>
I would like to know what guidelines are being followed with regard to the changes in attachment 12871 [details] [review]. Is there a particular reference guide we're following? I'm thinking that as each new kind of template change is submitted, a page in the wiki could also be updated adding the new coding guideline?
I have addeded an accessibility page in the development section of koha-wiki, which essentially summarises WAI guidelines. Coming to guidelines that are being followed specifically in relation to attachement 12871, point-wise: --> 1) Added labels to Search history and x links in the top frame According G131 of WAI guidelines: The objective of this technique is to ensure that the label for any interactive component within Web content makes the component's purpose clear. --> 2) Changed search results message from <strong> to <h3> As per our accessibility expert at Catalyst IT, it is advised to use headings instead of strong/bold tags, where possible, as screen readers can pick up headings. --> 3) Added the 'alt="cover image"' message to those entries that have cover images WAI recommends providing altenative text description of images.
(In reply to comment #5) > I have addeded an accessibility page in the development section of > koha-wiki, which essentially summarises WAI guidelines. Thank you! > --> 3) Added the 'alt="cover image"' message to those entries that have > cover images > > WAI recommends providing alternative text description of images. I disagree with this change. Alternative text should be used when an image is being used to convey information which would be lost if the image cannot be seen. Book cover images convey information, but that information cannot be conveyed in alt text--and we already display the book information as text. I don't think the alt attribute should ever be used to say something generic like "image." What use is it to the blind user (for example) to know that there is an image there? Better to use alt="" in cases where the image adds no useful information.
(In reply to comment #6) > (In reply to comment #5) > > I have addeded an accessibility page in the development section of > > koha-wiki, which essentially summarises WAI guidelines. > > Thank you! > > > --> 3) Added the 'alt="cover image"' message to those entries that have > > cover images > > > > WAI recommends providing alternative text description of images. > > I disagree with this change. Alternative text should be used when an image > is being used to convey information which would be lost if the image cannot > be seen. Book cover images convey information, but that information cannot > be conveyed in alt text--and we already display the book information as text. > > I don't think the alt attribute should ever be used to say something generic > like "image." What use is it to the blind user (for example) to know that > there is an image there? Better to use alt="" in cases where the image adds > no useful information. Not sure that is more useful than letting them know it is a cover image. Now they have no idea if that image was useful or not, just blank. At least if it says cover image, they know what it is. If you ever get the chance to see a user using a screen reader Owen, it is fascinating, one of the things they do is essentially read the page .. to learn a site. Having it tell them these are cover images lets them safely ignore them. Thats my 2 cents anyway.
(In reply to comment #7) > Having it tell them these are cover images lets them safely > ignore them. But doesn't 'alt=""' tell the screen reader to ignore the image altogether, meaning the user doesn't have to take the time to skip over it?
(In reply to comment #8) > (In reply to comment #7) > > Having it tell them these are cover images lets them safely > > ignore them. > > But doesn't 'alt=""' tell the screen reader to ignore the image altogether, > meaning the user doesn't have to take the time to skip over it? Maybe, but then they don't get an impression of what is on the page. IE Julius at least, liked to get a feel for what the page is like.
Some screen readers seem to give the structure of the page. For example, Julius could make out that when you search for a keyword the results are displayed in a table format containing 4 columns - check box, item index, item details and something that he couldn't interpret. I tried using alt="" and orca reads it as "opac details link image", which is what you get even when you don't have alt atribute at all. I support using alt="Cover Image" as it gives blind users an idea of what is on page rather than thinking that they are missing out on some information.
Created attachment 13030 [details] [review] Bug 8712 Made changes to advances search page to make it more accessibility friendly
Created attachment 13065 [details] [review] Bug 8712 - Made changes to advances search page to make it more accessibility friendly
I don't understand the changes to the default search types when "more options" is selected. Why make the default additional choices "title" and "author?" And if we're pre-selecting new options, why not add a "selected" attribute to the option instead of rearranging the choices?
Changing the default indexes is also a bad idea because of a bug in Koha. There is a good reason why they should remain keyword from top to bottom. Say you have 3 fields and those are preselected: Author _____ Title _____ Keyword _____ Now you go and enter your search terms into Title leaving the first search option for Author empty - Koha will search for your search terms in Author. That's one more reason we really need the search rewrite.
Is adding "and" to the default advanced search page important because having the label improves accessibility or because it emphasizes the boolean "AND" search aspect? If adding a label to the default search is important for accessibility, is it also an accessibility problem that there are two fields and only one label?
Created attachment 13088 [details] [review] bug 8712 - changed "New list" to "Create new list" This makes it clear for screen reader users.
I am trying to redo the changes in made in patch 13065 by breaking them into smaller independent tasks. I will try to address all the comments/questions based on this patch in the subsequent attachements to follow.
Created attachment 13090 [details] [review] bug 8712 - changed search results heading from <strong> to <h4> 1) Screen reader users can navigate a webpage using headers, this change enables that feature. 2) Added a new class "header-inline" to opac.css and used it with the above <h4> tag to prevent the line change between the header and subscribe feed image that follows it.
Created attachment 13091 [details] [review] [DOES NOT APPLY] bug 8712 - added labels to the "Search history" and "x" links in the top frame 1) Added labels to the above links to improve the accesibility. G131 of WAI guidelines: The objective of this technique is to ensure that the label for any interactive component within Web content makes the component's purpose clear. 2) Added a new class "off-left" to "opac.css" file to hide these labels from appearing on the page.
Created attachment 13092 [details] [review] [DOES NOT APPLY] bug 8712 - added alternative text to cover images shown in the search results This text informs screen reader users that the link is a cover image. At the moment, orca reads this link as "opac detail link image", which is confusing. Moreover, the images in individual records already contain 'alt="Cover Image"' attribute, the present addition will only make it more consistent. Also, according to WAI, "Images should include equivalent alternative text in the markup/code"[1]. References: 1) http://www.w3.org/standards/webdesign/accessibility
Created attachment 13093 [details] [review] [DOES NOT APPLY] bug 8712 - changed search results heading from <strong> to <h4> 1) Screen reader users can navigate a webpage using headers, this change enables that feature. 2) Added a new class "header-inline" to opac.css and used it with the above <h4> tag to prevent the line change between the header and subscribe feed image that follows it.
Comment on attachment 13090 [details] [review] bug 8712 - changed search results heading from <strong> to <h4> >From a89f10f6952b81ed3852fce1eb3394eb5e4eb573 Mon Sep 17 00:00:00 2001 >From: Srikanth Dhondi <srikanth@catalyst.net.nz> >Date: Mon, 29 Oct 2012 14:25:43 +1300 >Subject: [PATCH] bug 8712 - changed search results heading from <strong> to > <h4> > >1) Screen reader users can navigate a webpage using headers, this change enables > that feature. >2) Added a new class "header-inline" to opac.css and used it with the above <h4> > tag to prevent the line change between the header and subscribe feed image that follows it. >--- > koha-tmpl/opac-tmpl/prog/en/css/opac.css | 3 +++ > koha-tmpl/opac-tmpl/prog/en/includes/masthead.inc | 4 ++-- > 2 files changed, 5 insertions(+), 2 deletions(-) > >diff --git a/koha-tmpl/opac-tmpl/prog/en/css/opac.css b/koha-tmpl/opac-tmpl/prog/en/css/opac.css >index 7ab95e0..647104e 100644 >--- a/koha-tmpl/opac-tmpl/prog/en/css/opac.css >+++ b/koha-tmpl/opac-tmpl/prog/en/css/opac.css >@@ -2820,3 +2820,6 @@ body#opac-main #opacmainuserblockmobile { > .tagweight9 { > font-size: 30px; > } >+.header-inline { >+ display: inline; >+} >diff --git a/koha-tmpl/opac-tmpl/prog/en/includes/masthead.inc b/koha-tmpl/opac-tmpl/prog/en/includes/masthead.inc >index b0793dc..4e40fb7 100644 >--- a/koha-tmpl/opac-tmpl/prog/en/includes/masthead.inc >+++ b/koha-tmpl/opac-tmpl/prog/en/includes/masthead.inc >@@ -169,10 +169,10 @@ > </div> > </div> > <div id="breadcrumbs" class="yui-g"> >-[% IF ( searchdesc ) %]<p>[% IF ( total ) %]<strong>Your search returned [% total |html %] results.</strong> [% IF ( related ) %] (related searches: [% FOREACH relate IN related %][% relate.related_search %][% END %]). [% END %] >+[% IF ( searchdesc ) %]<p>[% IF ( total ) %]<h4 class="heading-inline">Your search returned [% total |html %] results.</h4> [% IF ( related ) %] (related searches: [% FOREACH relate IN related %][% relate.related_search %][% END %]). [% END %] > <a href="[% OPACBaseURL %]/cgi-bin/koha/opac-search.pl?[% query_cgi |html %][% limit_cgi |html %]&count=[% countrss |html %]&sort_by=acqdate_dsc&format=rss2" class="rsssearchlink"><img src="/opac-tmpl/prog/images/feed-icon-16x16.png" alt="Subscribe to this search" title="Subscribe to this search" border="0" class="rsssearchicon"/></a> > [% ELSE %] >-<strong>No results found!</strong> >+<h4>No results found!</h4> > <p> > [% IF ( searchdesc ) %] > No results found for that in [% LibraryName %] catalog. <a href="[% OPACBaseURL %]/cgi-bin/koha/opac-search.pl?[% query_cgi |html %][% limit_cgi |html %]&format=rss2" class="rsssearchlink"><img src="/opac-tmpl/prog/images/feed-icon-16x16.png" alt="Subscribe to this search" title="Subscribe to this search" border="0" class="rsssearchicon"/></a> >-- >1.7.9.5
oops
Created attachment 13106 [details] [review] bug 8712 - adding 'and' label for options in advanced search with fewer options The "and" label not only improves the accessibility but also gives the user an idea that the operation between multiple search fields is a boolean "AND" by default.
Created attachment 13107 [details] [review] [DOES NOT APPLY] bug 8712 - pre-selected options for search-field options in advanced search This pre-selected implementation of search field options in the advanced search gives users a better contrast in that it indicates that they can refine search for an item using three different attributes. In the current advanced search all three search fields contain "Keyword", which is confusing. For example, our Accessibility Expert thought that he could search for three different records/items using the three keyword fields.
(In reply to comment #14) > Changing the default indexes is also a bad idea because of a bug in Koha. > There is a good reason why they should remain keyword from top to bottom. > Say you have 3 fields and those are preselected: > > Author _____ > Title _____ > Keyword _____ > > Now you go and enter your search terms into Title leaving the first search > option for Author empty - Koha will search for your search terms in Author. > > That's one more reason we really need the search rewrite. I agree with Katrin, the attachement #13107 should only be included after the search code has been cleaned up.
Applying: bug 8712 - changed "New list" to "Create new list" bug 8712 - added labels to the "Search history" and "x" links in the top frame Apply? [yn] y Applying: bug 8712 - added labels to the "Search history" and "x" links in the top frame fatal: sha1 information is lacking or useless (koha-tmpl/opac-tmpl/prog/en/css/opac.css). Repository lacks necessary blobs to fall back on 3-way merge. Cannot fall back to three-way merge. Patch failed at 0001 bug 8712 - added labels to the "Search history" and "x" links in the top frame
Created attachment 14300 [details] [review] [SIGNED-OFF] Bug 8712 - We should use WAI-ARIA guidelines to help with accessibility Added title to the search box Signed-off-by: Owen Leonard <oleonard@myacpl.org> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
First patch passed QA, please switch back to 'Needs Signoff' later.
This patch has been pushed to master.
Created attachment 18784 [details] [review] [SIGNED_OFF] bug 8712 - changed "New list" to "Create new list" This makes it clear for screen reader users. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Note that you should delete all you private lists to see this change.
Comment on the New list-patch: If you click on Create new list, you will again see a 'New list' button. See /cgi-bin/koha/opac-shelves.pl?display=privateshelves.
Created attachment 18785 [details] [review] [SIGNED_OFF] bug 8712 - adding 'and' label for options in advanced search with fewer options The "and" label not only improves the accessibility but also gives the user an idea that the operation between multiple search fields is a boolean "AND" by default. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Actually only adds a label and an id to the select. Note that the boxes do not exactly align anymore now (with fewer options).
Status to Signed off for two patches.
Wondering if this is an enhancement or a bugfix. The two patches signed off, pass QA too: just simple template changes. For the five I would recommend a design followup though.
I've pushed to two QAed patches to master. Thanks, Srikanth!
The latest patches have been pushed to 3.12.x, will be in 3.12.5. Thanks Srikanth!
Resetting assignee, no change since 2013.
The situation on this bug is a little confusing, but it appears the patches have been pushed and there is nothing linked. We do have other accessibility bugs that cover the general idea, so closing this one. Please reopen if still see merit in this bug!