Am 01/19/2014 01:43 AM, schrieb Marcus (OOo):
Am 01/16/2014 12:17 AM, schrieb Dave Fisher:
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.
Sure, of course. I just hadn't the mood and time to dig into the code
what it is.
I've added a h1 tag with no text and disabled styles
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.
The order is important? Really? Didn't know this.
OK, fixed now:
http://ooo-site.staging.apache.org/index.html
In the meantime it's already online on www.oo.o. I've added a h1 tag and
fixed the double-link problem.
@Rob:
Please can you test if this is now OK in the screen reader?
Thanks
Marcus
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
