openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <>
Subject Re: First look at accesibility
Date Wed, 15 Jan 2014 23:17:47 GMT

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:
>>>> <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
>>>> 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:
> 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
>>>> 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="" />
>>> New:
>>> <html xmlns="" 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 ( 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="" 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?


>>>> 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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message