W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > January to March 2015

Re: best way to make content visible only to screen readers ??

From: Adam Powell <adam@adaminfinitum.com>
Date: Fri, 27 Feb 2015 09:40:38 -0500
Message-ID: <CALsiKnPyAaiY5aYaH+wFe3FwNAKJmrjumBpWfSW7DPu1xi99rQ@mail.gmail.com>
To: Mitchell Evan <mtchllvn@gmail.com>
Cc: "Michael A. Peters" <mpeters@domblogger.net>, WAI Interest Group <w3c-wai-ig@w3.org>
The HTML5 Boilerplate (which is an active and maintained collection of
"best practices" code for websites) uses a CSS class of `visuallyhidden`

They have some other improvements, inline comments and links to resources
as well.

You can currently view that on lines 118 - 167 of this file:

https://github.com/h5bp/html5-boilerplate/blob/master/dist/css/main.css

I personally use that method/code but I have never actually tested it, I
just take it at face value that the community of contributors around the
globe has effectively vetted it.

Hope it helps.

*Adam Powell*
Learn more at my website: Adam Infinitum <http://www.adaminfinitum.com>


On Fri, Feb 27, 2015 at 1:37 AM, Mitchell Evan <mtchllvn@gmail.com> wrote:

> Michael,
>
> I like how you're thinking about diversity of users and technologies.
>
> I recommend you keep the skip link for small screens. People do use
> keyboards and keyboard-like hardware on phones.
>
> Some of these users are not running a screen reader: for example, an
> adaptive switch user. So I recommend making the skip link visible when it
> gets focus, as described in the WebAIM link you sent. If you have limited
> space to display it, then try giving the link absolute positioning when
> it's shown.
>
> If you are using media queries, you're not just targeting mobile devices.
> You're also targeting browser zoom on the desktop. Meanwhile some phone
> displays are pretty wide. It's useful to think beyond mobile touchscreen
> and desktop keyboard/mouse, and consider all combinations of hardware
> interfaces.
>
> You should be able to use a visually-hidden CSS technique for a list item.
> There's an updated version of the CSS clip method at the following link. I
> was able to reproduce the WebKit scrollbar issue recently, so I recommend
> this fix for it.
>
> https://developer.yahoo.com/blogs/ydn/clip-hidden-content-better-accessibility-53456.html
>
> There's another possibility. What if all of your header content were
> tucked inside a single menu, followed by a clear visual and semantic
> indicator of the start of your main content? If there's hardly anything to
> skip, then there's no need for a skip link. If appropriate for the nature
> of the web site, this radical simplicity could benefit everybody.
> On Feb 26, 2015 4:41 PM, "Michael A. Peters" <mpeters@domblogger.net>
> wrote:
>
>> On my desktop design there isn't a problem.
>>
>> My header is absolute positioned with a z-index, so scrolling it is
>> always there for visual display.
>>
>> First link goes to #content - and thus serves for accessibility to skip
>> to the content and as a way for users of graphical browsers to easily
>> return to the top.
>>
>> Mobile I do not do absolute positioning because of the screen real
>> estate, the header scrolls with the page. And due to limited width of
>> screen, I try to conserve menu items in it.
>>
>> Since that first link to #content just takes up limited space in a
>> potentially 320px wide screen and is only visible when the page is already
>> at the top, I remove it.
>>
>> But I wonder if rather than remove it, I should just hide it from visible
>> display but keep it for assistive technology that may be in use on a phone
>> or small tablet?
>>
>> I looked at http://webaim.org/techniques/css/invisiblecontent/
>>
>> This link to #content is part of an unordered list, I'm not sure the CSS
>> clip method would work well.
>>
>> Is there no attribute / CSS that has the effect of display: none; but
>> that screen readers WILL still read?
>>
>> I don't know how assistive technology on phones works, is it important to
>> keep that #content link as the first on phones?
>>
>>
Received on Friday, 27 February 2015 14:41:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 13 October 2015 16:21:54 UTC