On Jan 14, 2014, at 3:03 PM, Marcus (OOo) wrote: > Am 01/14/2014 06:53 PM, schrieb Rob Weir: >> On Mon, Jan 13, 2014 at 4:09 PM, Marcus (OOo)<marcus.m...@wtnet.de> wrote: >>> Am 01/13/2014 07:52 PM, schrieb Rob Weir: >>> >>>> I've been scanning pages on our website to see what kinds of A11Y >>>> issues we should take care off. I'm concentrated initially on issues >>>> on our most popular pages as well as issues on the template, since the >>>> template generates the repeated headers/footers nad navigation on >>>> every page. We'll get more 'bang for the buck' if we can get the >>>> template perfect. >>>> >>>> Some of the kinds of issues I'm seeing: >>>> >>>> 1) The site-search button and input field in the upper right of the >>>> template. These were not coordinated in the best way. Since there is >>>> no associated label for the input field, I added a "title" attribute, >>>> so what we have now looks like this: >>>> >>>> <div class="topsrchbox"> >>>> <input name="resultsPerPage" value="40" type="hidden"/> >>>> <input name="q" id="query" type="text" title="search query"/> >>>> <input name="Button" value="search" type="submit" >>>> class="topsrchbutton"/> >>>> </div> >>> >>> >>> That means now the screen reader reads the title and converts it as voice >>> output, right? >>> >> >> Yes, that's my understanding. When we view the page this is clear >> from the visual context: a text input next to a button labeled >> "search" is for the search query. But the context is not always clear >> with a screen reader so we need to make it explicit. >> >>> >>>> 2) The home page uses<h2> headers to mark the main options on the >>>> page, e.g., "I want to download OpenOffice". But there is no<h1>. >>>> The doc I read said this inconsistency can confuse navigation via a >>>> screen reader. One option might be to make these all be<h1> and then >>>> adjust the CSS accordingly. Or maybe they should be an<ul> list? >>>> I have no made any fix here yet. >>> >>> >>> Simply insert a h1 headline, like: >>> >>> <h1>How can OpenOffice help you?</h1> >>> >>> However, if there is no need for one, then a hidden h1 could help to solve >>> the confusion but also keep the current webpage conent and style. >>> >>> The "hidden" attribute seems to look like the best option but maybe not as >>> it seems not to work in MS IE. Could someone test this? >>> >>> <h1 hidden>How can OpenOffice help you</h1> >>> >> >> The<h1> would be the parent of all the<h2>'s, including "Recent blog >> posts". So not just the left column. A hidden<h1> might stop the >> warning message, but I'm to sure it really fixes the problem. But >> this might be the lesser of the problems. At least we're not >> inconsistent in our headers, e.g., having an<h2> under an<h3> or >> something like that. >> >> >>> Or maybe just an empty h1 if this doesn't destroy the layout, like: >>> >>> <h1></h1> > > A h1 tag would create a headline with CSS blue box styling - like you can see > here: > http://www.openoffice.org/download/checksums.html > > Even with an empty h1 tag the blue box would be visible. So, if we decide to > insert a h1 tag, then with text.
You could turn off style with a tag in the h1. > >>>> 3) For each of the choices we seem to have two hyperlinks going to the >>>> same place: >>>> >>>> <div class="action-help"> >>>> <div class="action-text action-link"> >>>> <h2><a href="/support/">I need help with my OpenOffice</a></h2> >>>> <p><a href="/support/">Help is at hand whenever you need >>>> it.</a></p> >>>> </div> >>>> </div> >>>> >>>> This repetition makes navigation via screen readers unnecessarily >>>> chatty. Is there some way we can eliminate the redundant links? >>> >>> >>> I don't think so. Otherwise we would give up the link in the headline or the >>> text. And the headline and text should have different text formatting, >>> right? >>> >>> Could this help to get enough differentiation? >>> >>> >>> <h2><a href="/support/">I need help with my OpenOffice</a></h2> >>> <p><a href="support/index.html">Help is at hand whenever you need >>> it.</a></p> >>> >> >> That might silence the warning message, but the problem is still >> there. The issue is someone navigating by keyboard will see every >> link twice in a row. So it is a matter of excess noise on the page. >> >> I wonder if it would be better to have the image and the<h2> be the >> live links, and not link the smaller long description? Then we might >> be able to put the image and the text all in one<a>? > > This seems to help and also produces no HTML error (verified via W3C HTML > validator): > > <div class="action-info"> > <div class="action-text action-link"> > <a href="/why/"><h2>I want to learn more about OpenOffice</h2> > <p>What is Apache OpenOffice? And why should I use it?</p></a> > </div> > </div> > > However, the text is now displayed in light-grey and doesn't change anymore > when moving the mouse over it (compare with the other texts). So, some > further CSS hacks are necessary. Up to now I haven't found the root cause. css needs to follow order so h2.a and p.a styles need to be copied into a.h2 and a.p styles - this may be tedious. That depends on the cascade. > >>>> 4) I read that the navigation menus, which we have on the top of every >>>> page, as well as on the side of many prominent pages, will be read by >>>> screen readers, making it harder to get to the actual main content of >>>> the page. I saw some recommendations to add a "skip navigation" link. >>>> Another source said the navigation links could be enclosed in a >>>> <map>. >>>> >>>> 5) The contrast in our navigators, with dark blue text on a pale blue >>>> background is 3.7:1. This is lower than the 4.5:1 recommendation for >>>> low vision. Since these colors are part of our visual scheme and our >>>> branding, we'll need to think carefully about how we can improve this. >>>> (Note: we don't necessarily need to change the hue. Using a darker >>>> shade for the text, or a lighter one for the background might work) >>>> >>>> 6) We're missing a language identifier on most pages. >>> >>> >>> That's easy: insert a language ID. ;-) >>> >>> Currently: >>> <html xmlns="http://www.w3.org/1999/xhtml"; /> >>> >>> New: >>> <html xmlns="http://www.w3.org/1999/xhtml"; lang="en" xml:lang="en"> >>> >> >> Yup. Since we support multiple languages we'd need to do this on a >> per-page basis, which is a pain. Some NL pages use a customized NL >> template which might help, but not all do this. > > OK, let me correct myself: ;-) > > The solution is easy. But excuting it is complex. > > What about this? > When doing this is for the main website (www.openoffice.org/) without any > localized sub-pages we would cover the very most page hits. And could then > analyze which sub-webpages are visited often, too, to change them area by > area. This can be done by updating the ssi setup Add to all ssi.mdtext files a language property Here is /fr/ssi.mdtext language: fr doctype: /doctype.html brand: /fr/brand.html footer: /footer.html topnav: /fr/topnav.html home: home Edit template/skeleton.html Change <html> to <html xmlns="http://www.w3.org/1999/xhtml"; lang="{{ ssi.headers.language }}" xml:lang=""{{ ssi.headers.language }}""> Rebuild ooo-site. Warning this is a "sledgehammer" change. All pages are changed. Any other skeleton changes for accessibility? Regards, Dave > >>>> I'll continue investigating, but that is what I've found initially. >>>> If anyone has ideas for these items, please let me know. >>> >>> >>> Thanks, I hope my comments help a bit to do little but get much. >>> >> >> Thanks! >> >> -Rob > > Marcus > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
