You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Rob Weir <ro...@apache.org> on 2014/01/13 19:52:03 UTC
First look at www.openoffice.org accesibility
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>
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.
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?
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.
I'll continue investigating, but that is what I've found initially.
If anyone has ideas for these items, please let me know.
Regards,
-Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: First look at www.openoffice.org accesibility
Posted by Louis Suárez-Potts <lu...@gmail.com>.
On 13-Jan-2014, at 13:52, Rob Weir <ro...@apache.org> wrote:
> I'll continue investigating, but that is what I've found initially.
> If anyone has ideas for these items, please let me know.
Thanks, Rob.
Don't we have any A11Y experts on this list or in the project? I can ask some acquaintances who were involved with ODF, if not (or also).
But as to making changes wrt h2, h1, etc. Do these pages that we'd change come from Apache or otherwise integrate into the the larger site? That is, would any change we make be in danger of reversion or otherwise affect navigation within Apache?
I'lll assume you actually thought this not obscure thought, too, and I'll figure the answer is "no," or its effectual equivalent, "shrug." But do let me know about scanning the pages for accessibility.
thanks
Louis
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: First look at www.openoffice.org accesibility
Posted by Kay Schenk <ka...@gmail.com>.
On Tue, Jan 14, 2014 at 9:53 AM, Rob Weir <ro...@apache.org> wrote:
> On Mon, Jan 13, 2014 at 4:09 PM, Marcus (OOo) <ma...@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>
> >
> >
> >> 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>?
>
you mean?...(with possibly additional changes for the image styling?)
<div class="action-help">
<div class="action-text action-link">
<h2><a href="/support/">I need help with my OpenOffice</a></h2>
<p>Help is at hand whenever you need it.</a></p>
</div>
</div>
Well, do it and see how you like it. Maybe post a graphic mockup on cwiki.
hmmm..should we start a new area on cwiki for accessibility changes to the
web site?
> >
> >> 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.
>
> >
> >> 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-unsubscribe@openoffice.apache.org
> > For additional commands, e-mail: dev-help@openoffice.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
--
-------------------------------------------------------------------------------------------------
MzK
"Cats do not have to be shown how to have a good time,
for they are unfailing ingenious in that respect."
-- James Mason
Re: First look at www.openoffice.org accesibility
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 01/22/2014 03:50 AM, schrieb Nancy K:
> I don't know if any of these links will help -
>
> Invisible content just for screen reader users:
> http://webaim.org/techniques/css/invisiblecontent/#techniques
Thanks for this. The H1 text is now styled with "display: none;".
> Cynthia Says for Section 508/WCAG2.0 (A thru AAA) accessibility (enter the url online):
> http://www.cynthiasays.com/?
>
> Colorblind tests (enter url online):
> http://colorfilter.wickline.org/
>
> html5 validator:
> html5.validator.nu
I've not yet looked into these webpages but I fear we will have much to
do. ;-)
Marcus
> ________________________________
> From: Rob Weir<ap...@robweir.com>
> To: "dev@openoffice.apache.org"<de...@openoffice.apache.org>
> Sent: Tuesday, January 21, 2014 1:39 PM
> Subject: Re: First look at www.openoffice.org accesibility
>
>
> On Tue, Jan 21, 2014 at 4:09 PM, Marcus (OOo)<ma...@wtnet.de> wrote:
>
>>
>>
>> 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
>>
>>
>
> Here's the tool I used to check:
>
> http://wave.webaim.org
>
> The duplicate links problem is gone. That's good news.
>
> The error about the missing<h1> is gone. But now it gives an error
> for the<h1> with no content.
>
> I wonder whether the "real" solution here is to make those main
> options into<h1>'s and update the CSS accordingly? If we use a
> specific class for those headers we won't conflict with the<h1>'s on
> other pages, which are styled differently.
>
> The only other error we have on the home page (and the other templated
> pages) is the lack of the language identifier, and it sounds like Dave
> had a good solution there.
>
> Regards,
>
> -RobboR
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: First look at www.openoffice.org accesibility
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 01/22/2014 04:53 AM, schrieb Rob Weir:
> On Tue, Jan 21, 2014 at 9:50 PM, Nancy K<na...@yahoo.com> wrote:
>> I don't know if any of these links will help -
>>
>> Invisible content just for screen reader users:
>> http://webaim.org/techniques/css/invisiblecontent/#techniques
>>
>
> Hmmm.... that might be the way to do it. Have the<h1> as Marcus did
> it, but give it text that a screen reader will see, like "What do you
> want to do today?" or something that would make sense as the parent of
> the home page options. But then use CSS to hide the text from the
> design. That's probably better than having an empty<h1>.
Right. I've done it exactly this way.
Marcus
>> Cynthia Says for Section 508/WCAG2.0 (A thru AAA) accessibility (enter the url online):
>> http://www.cynthiasays.com/?
>>
>> Colorblind tests (enter url online):
>> http://colorfilter.wickline.org/
>>
>> html5 validator:
>> html5.validator.nu
>>
>>
>> Nancy
>>
>> Nancy Web Design
>> Free 24 hour pass to lynda.com.
>> Video courses on SEO, CMS,
>> Design and Software Courses
>>
>>
>>
>>
>> ________________________________
>> From: Rob Weir<ap...@robweir.com>
>> To: "dev@openoffice.apache.org"<de...@openoffice.apache.org>
>> Sent: Tuesday, January 21, 2014 1:39 PM
>> Subject: Re: First look at www.openoffice.org accesibility
>>
>>
>> On Tue, Jan 21, 2014 at 4:09 PM, Marcus (OOo)<ma...@wtnet.de> wrote:
>>
>>>
>>>
>>> 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
>>>
>>>
>>
>> Here's the tool I used to check:
>>
>> http://wave.webaim.org
>>
>> The duplicate links problem is gone. That's good news.
>>
>> The error about the missing<h1> is gone. But now it gives an error
>> for the<h1> with no content.
>>
>> I wonder whether the "real" solution here is to make those main
>> options into<h1>'s and update the CSS accordingly? If we use a
>> specific class for those headers we won't conflict with the<h1>'s on
>> other pages, which are styled differently.
>>
>> The only other error we have on the home page (and the other templated
>> pages) is the lack of the language identifier, and it sounds like Dave
>> had a good solution there.
>>
>> Regards,
>>
>> -RobboR
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: First look at www.openoffice.org accesibility
Posted by Rob Weir <ro...@apache.org>.
On Tue, Jan 21, 2014 at 9:50 PM, Nancy K <na...@yahoo.com> wrote:
> I don't know if any of these links will help -
>
> Invisible content just for screen reader users:
> http://webaim.org/techniques/css/invisiblecontent/#techniques
>
Hmmm.... that might be the way to do it. Have the <h1> as Marcus did
it, but give it text that a screen reader will see, like "What do you
want to do today?" or something that would make sense as the parent of
the home page options. But then use CSS to hide the text from the
design. That's probably better than having an empty <h1>.
Thanks!
-Rob
> Cynthia Says for Section 508/WCAG2.0 (A thru AAA) accessibility (enter the url online):
> http://www.cynthiasays.com/?
>
> Colorblind tests (enter url online):
> http://colorfilter.wickline.org/
>
> html5 validator:
> html5.validator.nu
>
>
> Nancy
>
> Nancy Web Design
> Free 24 hour pass to lynda.com.
> Video courses on SEO, CMS,
> Design and Software Courses
>
>
>
>
> ________________________________
> From: Rob Weir <ap...@robweir.com>
> To: "dev@openoffice.apache.org" <de...@openoffice.apache.org>
> Sent: Tuesday, January 21, 2014 1:39 PM
> Subject: Re: First look at www.openoffice.org accesibility
>
>
> On Tue, Jan 21, 2014 at 4:09 PM, Marcus (OOo) <ma...@wtnet.de> wrote:
>
>>
>>
>> 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
>>
>>
>
> Here's the tool I used to check:
>
> http://wave.webaim.org
>
> The duplicate links problem is gone. That's good news.
>
> The error about the missing <h1> is gone. But now it gives an error
> for the <h1> with no content.
>
> I wonder whether the "real" solution here is to make those main
> options into <h1>'s and update the CSS accordingly? If we use a
> specific class for those headers we won't conflict with the <h1>'s on
> other pages, which are styled differently.
>
> The only other error we have on the home page (and the other templated
> pages) is the lack of the language identifier, and it sounds like Dave
> had a good solution there.
>
> Regards,
>
> -RobboR
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: First look at www.openoffice.org accesibility
Posted by Nancy K <na...@yahoo.com>.
I don't know if any of these links will help -
Invisible content just for screen reader users:
http://webaim.org/techniques/css/invisiblecontent/#techniques
Cynthia Says for Section 508/WCAG2.0 (A thru AAA) accessibility (enter the url online):
http://www.cynthiasays.com/?
Colorblind tests (enter url online):
http://colorfilter.wickline.org/
html5 validator:
html5.validator.nu
Nancy
Nancy Web Design
Free 24 hour pass to lynda.com.
Video courses on SEO, CMS,
Design and Software Courses
________________________________
From: Rob Weir <ap...@robweir.com>
To: "dev@openoffice.apache.org" <de...@openoffice.apache.org>
Sent: Tuesday, January 21, 2014 1:39 PM
Subject: Re: First look at www.openoffice.org accesibility
On Tue, Jan 21, 2014 at 4:09 PM, Marcus (OOo) <ma...@wtnet.de> wrote:
>
>
> 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
>
>
Here's the tool I used to check:
http://wave.webaim.org
The duplicate links problem is gone. That's good news.
The error about the missing <h1> is gone. But now it gives an error
for the <h1> with no content.
I wonder whether the "real" solution here is to make those main
options into <h1>'s and update the CSS accordingly? If we use a
specific class for those headers we won't conflict with the <h1>'s on
other pages, which are styled differently.
The only other error we have on the home page (and the other templated
pages) is the lack of the language identifier, and it sounds like Dave
had a good solution there.
Regards,
-RobboR
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: First look at www.openoffice.org accesibility
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
[Top post to give you the latest update]
I've done fixed on the homepage [1] and download webpage [2].
The remaining things to fix are a missing title in the search box (top
right) and the missing lang ID. Both applies to the entire website and
not only to the both.
To be continued ...
[1] http://www.openoffice.org
[2] http://www.openoffice.org/download/
Marcus
Am 01/21/2014 10:39 PM, schrieb Rob Weir:
> On Tue, Jan 21, 2014 at 4:09 PM, Marcus (OOo)<ma...@wtnet.de> wrote:
>
>>
>>
>> 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
>>
>>
>
> Here's the tool I used to check:
>
> http://wave.webaim.org
>
> The duplicate links problem is gone. That's good news.
>
> The error about the missing<h1> is gone. But now it gives an error
> for the<h1> with no content.
>
> I wonder whether the "real" solution here is to make those main
> options into<h1>'s and update the CSS accordingly? If we use a
> specific class for those headers we won't conflict with the<h1>'s on
> other pages, which are styled differently.
>
> The only other error we have on the home page (and the other templated
> pages) is the lack of the language identifier, and it sounds like Dave
> had a good solution there.
>
> Regards,
>
> -RobboR
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: First look at www.openoffice.org accesibility
Posted by Rob Weir <ap...@robweir.com>.
On Tue, Jan 21, 2014 at 4:09 PM, Marcus (OOo) <ma...@wtnet.de> wrote:
>
>
> 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
>
>
Here's the tool I used to check:
http://wave.webaim.org
The duplicate links problem is gone. That's good news.
The error about the missing <h1> is gone. But now it gives an error
for the <h1> with no content.
I wonder whether the "real" solution here is to make those main
options into <h1>'s and update the CSS accordingly? If we use a
specific class for those headers we won't conflict with the <h1>'s on
other pages, which are styled differently.
The only other error we have on the home page (and the other templated
pages) is the lack of the language identifier, and it sounds like Dave
had a good solution there.
Regards,
-RobboR
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: First look at www.openoffice.org accesibility
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
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)<ma...@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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: First look at www.openoffice.org accesibility
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
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)<ma...@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
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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: First look at www.openoffice.org accesibility
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 01/16/2014 04:22 PM, schrieb Rob Weir:
> On Wed, Jan 15, 2014 at 6:17 PM, Dave Fisher<da...@comcast.net> wrote:
>>
> .
> .
> .
>
>>
>> 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?
>>
>
> The other change -- which probably needs more discussion -- is to
> implement some form of "skiplinks". The current problem is a user
> needs to tab over the navigation links on every page they load before
> they get to the actual page contents. Best practice is to have some
> short cut to go directly to navigation, to content, to footer. The
> tricky thing is to do this in a way that works well with the page
> design as well.
>
> This page implements it in a clever way:
>
> http://accessites.org/site/2006/05/skip-link-pros-and-cons/
Nice way to present the user a shortcut to some common link groups.
> Hit tab a couple times in your browser and you'll see the links show
> up in the upper right. This is done with CSS tricks to position the
> <ul> off screen except when it has the focus.
>
>
> So they have this meta-navigation:
>
> <ul class="offset">
> <li><a href="#content">Jump to Content</a></li>
> <li><a href="#nav">Jump to Navigation</a></li>
> <li><a href="#footer">Jump to Footer</a></li>
> </ul>
>
> And from http://accessites.org/site/wp-content/themes/beastblog-v2/style.css:
>
> ul.offset, .offset {
> position : absolute;
> top : -9000px;
> left : -9000px;
> z-index : 9;
> }
>
> ul.offset a:focus, ul.offset a:active {
> position : absolute;
> top : 9010px;
> left : 9010px;
> background-color : #339999;
> color : #fff;
> padding : 5px;
> font-weight : bold;
> border : 2px solid #000;
> width : 6em;
> z-index : 9;
> }
>
> So navigation menu is 9000 pixels off the screen, except when it has
> the focus, in which case it is brought in net 10 pixels.
>
> But I wonder what happens if you try to print a page like that.
> Hopefully the browsers are smart enough not to print many blank pages
> followed by the off-screen menu...
My Firefox want to print 6 pages with only the expected content.
> The complication with our website is that we have side menu navigation
> on some (but not all pages). But we have top nav, and footer, on all
> pages.
>
> Regards,
>
> -Rob
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: First look at www.openoffice.org accesibility
Posted by Rob Weir <ro...@apache.org>.
On Wed, Jan 15, 2014 at 6:17 PM, Dave Fisher <da...@comcast.net> wrote:
>
.
.
.
>
> 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?
>
The other change -- which probably needs more discussion -- is to
implement some form of "skiplinks". The current problem is a user
needs to tab over the navigation links on every page they load before
they get to the actual page contents. Best practice is to have some
short cut to go directly to navigation, to content, to footer. The
tricky thing is to do this in a way that works well with the page
design as well.
This page implements it in a clever way:
http://accessites.org/site/2006/05/skip-link-pros-and-cons/
Hit tab a couple times in your browser and you'll see the links show
up in the upper right. This is done with CSS tricks to position the
<ul> off screen except when it has the focus.
So they have this meta-navigation:
<ul class="offset">
<li><a href="#content">Jump to Content</a></li>
<li><a href="#nav">Jump to Navigation</a></li>
<li><a href="#footer">Jump to Footer</a></li>
</ul>
And from http://accessites.org/site/wp-content/themes/beastblog-v2/style.css:
ul.offset, .offset {
position : absolute;
top : -9000px;
left : -9000px;
z-index : 9;
}
ul.offset a:focus, ul.offset a:active {
position : absolute;
top : 9010px;
left : 9010px;
background-color : #339999;
color : #fff;
padding : 5px;
font-weight : bold;
border : 2px solid #000;
width : 6em;
z-index : 9;
}
So navigation menu is 9000 pixels off the screen, except when it has
the focus, in which case it is brought in net 10 pixels.
But I wonder what happens if you try to print a page like that.
Hopefully the browsers are smart enough not to print many blank pages
followed by the off-screen menu...
The complication with our website is that we have side menu navigation
on some (but not all pages). But we have top nav, and footer, on all
pages.
Regards,
-Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: First look at www.openoffice.org accesibility
Posted by Dave Fisher <da...@comcast.net>.
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)<ma...@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-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: First look at www.openoffice.org accesibility
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 01/14/2014 06:53 PM, schrieb Rob Weir:
> On Mon, Jan 13, 2014 at 4:09 PM, Marcus (OOo)<ma...@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.
>>> 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.
>>> 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.
>>> 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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: First look at www.openoffice.org accesibility
Posted by Rob Weir <ro...@apache.org>.
On Mon, Jan 13, 2014 at 4:09 PM, Marcus (OOo) <ma...@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>
>
>
>> 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>?
>
>> 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.
>
>> 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-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: First look at www.openoffice.org accesibility
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
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?
> 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>
Or maybe just an empty h1 if this doesn't destroy the layout, like:
<h1></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>
> 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">
> 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.
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org