Re: First look at www.openoffice.org accesibility

2014-01-22 Thread Marcus (OOo)

[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)  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  is gone.  But now it gives an error
for the  with no content.

I wonder whether the "real" solution here is to make those main
options into's and update the CSS accordingly?  If we use a
specific class for those headers we won't conflict with the'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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: First look at www.openoffice.org accesibility

2014-01-22 Thread Marcus (OOo)

Am 01/22/2014 04:53 AM, schrieb Rob Weir:

On Tue, Jan 21, 2014 at 9:50 PM, Nancy K  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  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.


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
To: "dev@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)  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  is gone.  But now it gives an error
for the  with no content.

I wonder whether the "real" solution here is to make those main
options into's and update the CSS accordingly?  If we use a
specific class for those headers we won't conflict with the'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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: First look at www.openoffice.org accesibility

2014-01-22 Thread Marcus (OOo)

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
To: "dev@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)  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  is gone.  But now it gives an error
for the  with no content.

I wonder whether the "real" solution here is to make those main
options into's and update the CSS accordingly?  If we use a
specific class for those headers we won't conflict with the'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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: First look at www.openoffice.org accesibility

2014-01-21 Thread Rob Weir
On Tue, Jan 21, 2014 at 9:50 PM, Nancy K  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  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 .

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 
> To: "dev@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)  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  is gone.  But now it gives an error
> for the  with no content.
>
> I wonder whether the "real" solution here is to make those main
> options into 's and update the CSS accordingly?  If we use a
> specific class for those headers we won't conflict with the '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-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



Re: First look at www.openoffice.org accesibility

2014-01-21 Thread 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

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 
To: "dev@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)  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  is gone.  But now it gives an error
for the  with no content.

I wonder whether the "real" solution here is to make those main
options into 's and update the CSS accordingly?  If we use a
specific class for those headers we won't conflict with the '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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: First look at www.openoffice.org accesibility

2014-01-21 Thread Rob Weir
On Tue, Jan 21, 2014 at 4:09 PM, Marcus (OOo)  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  is gone.  But now it gives an error
for the  with no content.

I wonder whether the "real" solution here is to make those main
options into 's and update the CSS accordingly?  If we use a
specific class for those headers we won't conflict with the '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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: First look at www.openoffice.org accesibility

2014-01-21 Thread Marcus (OOo)

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)
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:









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 headers to mark the main options on the
page, e.g., "I want to download OpenOffice". But there is no.
The doc I read said this inconsistency can confuse navigation via a
screen reader. One option might be to make these all be and then
adjust the CSS accordingly. Or maybe they should be an list?
I have no made any fix here yet.



Simply insert a h1 headline, like:

How can OpenOffice help you?

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?

How can OpenOffice help you



The would be the parent of all the's, including "Recent blog
posts". So not just the left column. A hidden 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 under an or
something like that.



Or maybe just an empty h1 if this doesn't destroy the layout, like:




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:



I need help with my OpenOffice
Help is at hand whenever you need
it.



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?


I need help with my OpenOffice
Help is at hand whenever you need
it.



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 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?


This seems to help and also produces no HTML error (verified via W3C
HTML validator):



I want to learn more about OpenOffice
What is Apache OpenOffice? And why should I use it?



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 

Re: First look at www.openoffice.org accesibility

2014-01-18 Thread 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)   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:


 
 
 
   



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 usesheaders to mark the main options on the
page, e.g., "I want to download OpenOffice".  But there is no.
The doc I read said this inconsistency can confuse navigation via a
screen reader.  One option might be to make these all beand then
adjust the CSS accordingly.Or maybe they should be anlist?
I have no made any fix here yet.



Simply insert a h1 headline, like:

How can OpenOffice help you?

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?

How can OpenOffice help you



The   would be the parent of all the's, including "Recent blog
posts".  So not just the left column.  A hidden   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   under an   or
something like that.



Or maybe just an empty h1 if this doesn't destroy the layout, like:




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:


  
I need help with my OpenOffice
Help is at hand whenever you need
it.
  


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?


I need help with my OpenOffice
Help is at hand whenever you need
it.



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   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?


This seems to help and also produces no HTML error (verified via W3C HTML 
validator):

  

  I want to learn more about OpenOffice
  What is Apache OpenOffice? And why should I use it?

  

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
.

5) The contrast in our navigators, with dark blu

Re: First look at www.openoffice.org accesibility

2014-01-18 Thread Marcus (OOo)

Am 01/16/2014 04:22 PM, schrieb Rob Weir:

On Wed, Jan 15, 2014 at 6:17 PM, Dave Fisher  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  tohttp://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
  off screen except when it has the focus.


So they have this meta-navigation:


  Jump to Content
  Jump to Navigation
  Jump to Footer


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 : #33;
   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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: First look at www.openoffice.org accesibility

2014-01-16 Thread Rob Weir
On Wed, Jan 15, 2014 at 6:17 PM, Dave Fisher  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  to 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
 off screen except when it has the focus.


So they have this meta-navigation:


 Jump to Content
 Jump to Navigation
 Jump to Footer


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 : #33;
  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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: First look at www.openoffice.org accesibility

2014-01-15 Thread 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)  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:
 
 
 
 
 >>> class="topsrchbutton"/>
   
>>> 
>>> 
>>> 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   headers to mark the main options on the
 page, e.g., "I want to download OpenOffice".  But there is no.
 The doc I read said this inconsistency can confuse navigation via a
 screen reader.  One option might be to make these all be   and then
 adjust the CSS accordingly.Or maybe they should be an   list?
 I have no made any fix here yet.
>>> 
>>> 
>>> Simply insert a h1 headline, like:
>>> 
>>> How can OpenOffice help you?
>>> 
>>> 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?
>>> 
>>> How can OpenOffice help you
>>> 
>> 
>> The  would be the parent of all the's, including "Recent blog
>> posts".  So not just the left column.  A hidden  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  under an  or
>> something like that.
>> 
>> 
>>> Or maybe just an empty h1 if this doesn't destroy the layout, like:
>>> 
>>> 
> 
> 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:
 
 
  
I need help with my OpenOffice
Help is at hand whenever you need
 it.
  

 
 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?
>>> 
>>> 
>>> I need help with my OpenOffice
>>> Help is at hand whenever you need
>>> it.
>>> 
>> 
>> 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  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?
> 
> This seems to help and also produces no HTML error (verified via W3C HTML 
> validator):
> 
>  
>
>  I want to learn more about OpenOffice
>  What is Apache OpenOffice? And why should I use it?
>
>  
> 
> 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 recommenda

Re: First look at www.openoffice.org accesibility

2014-01-14 Thread Marcus (OOo)

Am 01/14/2014 06:53 PM, schrieb Rob Weir:

On Mon, Jan 13, 2014 at 4:09 PM, Marcus (OOo)  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:


 
 
 
   



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   headers to mark the main options on the
page, e.g., "I want to download OpenOffice".  But there is no.
The doc I read said this inconsistency can confuse navigation via a
screen reader.  One option might be to make these all be   and then
adjust the CSS accordingly.Or maybe they should be an   list?
I have no made any fix here yet.



Simply insert a h1 headline, like:

How can OpenOffice help you?

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?

How can OpenOffice help you



The  would be the parent of all the's, including "Recent blog
posts".  So not just the left column.  A hidden  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  under an  or
something like that.



Or maybe just an empty h1 if this doesn't destroy the layout, like:




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:


  
I need help with my OpenOffice
Help is at hand whenever you need
it.
  


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?


I need help with my OpenOffice
Help is at hand whenever you need
it.



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  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?


This seems to help and also produces no HTML error (verified via W3C 
HTML validator):


  

  I want to learn more about OpenOffice
  What is Apache OpenOffice? And why should I use it?

  

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
.

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:
http://www.w3.org/1999/xhtml"; />

New:
http://www.w3.org/1999/xhtml"; lang="en" x

Re: First look at www.openoffice.org accesibility

2014-01-14 Thread Kay Schenk
On Tue, Jan 14, 2014 at 9:53 AM, Rob Weir  wrote:

> On Mon, Jan 13, 2014 at 4:09 PM, Marcus (OOo) 
> 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:
> >>
> >> 
> >> 
> >> 
> >>  >> class="topsrchbutton"/>
> >>   
> >
> >
> > 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  headers to mark the main options on the
> >> page, e.g., "I want to download OpenOffice".  But there is no.
> >> The doc I read said this inconsistency can confuse navigation via a
> >> screen reader.  One option might be to make these all be  and then
> >> adjust the CSS accordingly.Or maybe they should be an  list?
> >> I have no made any fix here yet.
> >
> >
> > Simply insert a h1 headline, like:
> >
> > How can OpenOffice help you?
> >
> > 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?
> >
> > How can OpenOffice help you
> >
>
> The  would be the parent of all the 's, including "Recent blog
> posts".  So not just the left column.  A hidden  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  under an  or
> something like that.
>
>
> > Or maybe just an empty h1 if this doesn't destroy the layout, like:
> >
> > 
> >
> >
> >> 3) For each of the choices we seem to have two hyperlinks going to the
> >> same place:
> >>
> >> 
> >>  
> >>I need help with my
> OpenOffice
> >>Help is at hand whenever you need
> >> it.
> >>  
> >>
> >>
> >> 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?
> >
> >
> > I need help with my OpenOffice
> > Help is at hand whenever you need
> > it.
> >
>
> 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  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 ?
>

you mean?...(with possibly additional changes for the image styling?)


 
   I need help with my OpenOffice
  Help is at hand whenever you need  it.
  
  

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
> >> .
> >>
> >> 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: ins

Re: First look at www.openoffice.org accesibility

2014-01-14 Thread Rob Weir
On Mon, Jan 13, 2014 at 4:09 PM, Marcus (OOo)  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:
>>
>> 
>> 
>> 
>> > class="topsrchbutton"/>
>>   
>
>
> 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  headers to mark the main options on the
>> page, e.g., "I want to download OpenOffice".  But there is no.
>> The doc I read said this inconsistency can confuse navigation via a
>> screen reader.  One option might be to make these all be  and then
>> adjust the CSS accordingly.Or maybe they should be an  list?
>> I have no made any fix here yet.
>
>
> Simply insert a h1 headline, like:
>
> How can OpenOffice help you?
>
> 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?
>
> How can OpenOffice help you
>

The  would be the parent of all the 's, including "Recent blog
posts".  So not just the left column.  A hidden  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  under an  or
something like that.


> Or maybe just an empty h1 if this doesn't destroy the layout, like:
>
> 
>
>
>> 3) For each of the choices we seem to have two hyperlinks going to the
>> same place:
>>
>> 
>>  
>>I need help with my OpenOffice
>>Help is at hand whenever you need
>> it.
>>  
>>
>>
>> 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?
>
>
> I need help with my OpenOffice
> Help is at hand whenever you need
> it.
>

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  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 ?

>
>> 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
>> .
>>
>> 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:
> http://www.w3.org/1999/xhtml"; />
>
> New:
> 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, 

Re: First look at www.openoffice.org accesibility

2014-01-13 Thread Louis Suárez-Potts

On 13-Jan-2014, at 13:52, Rob Weir  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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: First look at www.openoffice.org accesibility

2014-01-13 Thread Marcus (OOo)

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:





  


That means now the screen reader reads the title and converts it as 
voice output, right?



2) The home page uses  headers to mark the main options on the
page, e.g., "I want to download OpenOffice".  But there is no.
The doc I read said this inconsistency can confuse navigation via a
screen reader.  One option might be to make these all be  and then
adjust the CSS accordingly.Or maybe they should be an  list?
I have no made any fix here yet.


Simply insert a h1 headline, like:

How can OpenOffice help you?

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?


How can OpenOffice help you

Or maybe just an empty h1 if this doesn't destroy the layout, like:




3) For each of the choices we seem to have two hyperlinks going to the
same place:


 
   I need help with my OpenOffice
   Help is at hand whenever you need it.
 
   

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?

I need help with my OpenOffice
Help is at hand whenever you need 
it.



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
.

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:
http://www.w3.org/1999/xhtml"; />

New:
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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org