[theme-reviewers] 'accessibility-ready' tag

Sat Jan 11 16:19:17 UTC 2014

There are two different types of text that might be hidden for screen
readers: text that is only ever of use to screen readers, and text that may
be of use to other users. Skiplinks usually fall into the latter category,
because those links are also of use to users who are keyboard-dependent,
but do not have a visual disability. For those types of links, you need to
bring them into site when they receive keyboard focus. This is required to
meet the WP accessibility-ready guidelines. For hiding, you can use either
set of styles; they're essentially equal.

For some other text - like form labels - it's acceptable to hide them so
that they're only available for screen readers.

Wrapping headers in a screen-reader class means that those headers are
available to screen readers to use for navigation, but not visible to other
users. Screen readers can generate navigation tools for users based on the
headings and heading structure for the page, but for design purposes, it
may not be useful or necessary to have those headings. Thus, you can hide
headings so that they're only useful for screen readers but don't interfere
with your design.

Whether using an H1 breaks the structure is highly dependent on many
factors. If the site is using the HTML5 heading model, which expressly
allows multiple H1 headers, then it's fine, as long as it's in a new
section container. It's legitimate, but in practice, the HTML5 headline
outline algorithms are incredibly poor, so it's not the best possible
choice.

Best,
Joe

On Sat, Jan 11, 2014 at 10:15 AM, Joe Dolson <joe at joedolson.com> wrote:

> There are two different types of text that might be hidden for screen
> readers: text that is only ever of use to screen readers, and text that may
> be of use to other users. Skiplinks usually fall into the latter category,
> because those links are also of use to users who are keyboard-dependent,
> but do not have a visual disability. For those types of links, you need to
> bring them into site when they receive keyboard focus. This is required to
> meet the WP accessibility-ready guidelines. For hiding, you can use either
> set of styles; they're essentially equal.
>
> For some other text - like form labels - it's acceptable to hide them so
> that they're only available for screen readers.
>
> Wrapping headers in a screen-reader class means that those headers are
> available to screen readers to use for navigation, but not visible to other
> users. Screen readers can generate navigation tools for users based on the
> headings and heading structure for the page, but for design purposes, it
> may not be useful or necessary to have those headings. Thus, you can hide
> headings so that they're only useful for screen readers but don't interfere
> with your design.
>
> Whether using an H1 breaks the structure is highly dependent on many
> factors. If the site is using the HTML5 heading model, which expressly
> allows multiple H1 headers, then it's fine, as long as it's in a new
> section container. It's legitimate, but in practice, the HTML5 headline
> outline algorithms are incredibly poor, so it's not the best possible
> choice.
>
> Best,
> Joe
>
>
>
> On Fri, Jan 10, 2014 at 7:12 PM, Bass Jobsen <bass at w3masters.nl> wrote:
>
>> Hi Joe,
>>
>> I'm still trying to get  'accessibility-ready' tag  for my theme.
>> I had to fix other issues first. Today i found i also have to fix for
>> accessibility. So i add the "skip links system" first (available on github
>> now https://github.com/bassjobsen/jamedo-bootstrap-start-theme).
>>
>> Doing this not all was clear for me. I got two questions:
>>
>> 1) I check twentyfourteen and found the .screen-reader-text class to hide
>> content for non-screen-readers. This class is short and has a longer focus
>> pseudo class.
>> Bootstrap has it own class (.sr-only) to do the same.
>> Both classes do the same but their implementation differs. For example
>> the sr-only don't has a focus at all.
>> Which one should i use or prefer? I why?
>>
>> 2) also in twentyfourteen i found some readreaders' navigation text
>> wrapped in h1. like
>> <h1 class="screen-reader-text"><?php _e( 'Comment navigation',
>> 'twentyfourteen' ); ?></h1>
>>
>> I wonder if choosing a header and especialy a h1 won't break the
>> hierarchical header structure which also is an  accessibility aspect.
>>
>> Thanks and best regards,
>>
>> Bass
>>
>> 2013/12/12 Joe Dolson <design at joedolson.com>
>>
>>> Hi, Bass - if you want to contact me off-list, feel free (
>>> joe at joedolson.com); but I'll answer this message on list here. Whether
>>> this is on-topic or not is hard to gauge. But I'm sure somebody will let me
>>> know!
>>>
>>> We haven't provided extensive options on the accessibility page because,
>>> frankly, it was already pretty lengthy, and it could easily become
>>> book-length. Since this is the first time these guidelines are going to be
>>> getting used, they will undoubtedly be tweaked in the coming months so that
>>> they are more friendly to those who use them!
>>>
>>> So, first: display: none;
>>>
>>> Yes, display:none; removes the hidden items from what a screen reader
>>> will provide. This isn't necessarily a problem, as long as a method is
>>> provided that brings it back into view, and which shares that information
>>> with screen readers. Using display:none, in itself, won't prevent your
>>> theme from meeting the accessibility-ready requirements, but the hidden
>>> resources need to have a specific method of bringing them back to focus.
>>> With a menu, that means something that you activate which focuses the menu.
>>> The menu parent should have an attribute of aria-live='polite' so that when
>>> the children are brought back into the DOM, screen reader's will announce
>>> the presence of the menu.
>>>
>>> I haven't done a thorough study of the BootStrap menus; but I think
>>> that's probably due, and will undoubtedly come up repeatedly in the next
>>> few months. Based on a quick test right now of BootStrap's demo (
>>> http://getbootstrap.com/javascript/#dropdowns), they appear to be
>>> accessible.
>>>
>>> But with accessibility, it's always necessary to do reviews of an actual
>>> implementation: one implementation being accessible does not mean that
>>> another will be.
>>>
>>> Best,
>>> Joe
>>>
>>>
>>> On Wed, Dec 11, 2013 at 5:31 PM, Bass Jobsen <bass at w3masters.nl> wrote:
>>>
>>>> Hi Joe,
>>>>
>>>> I read your message about the 'accessibility-ready' and found it
>>>> very interesting. I'm a theme developer, so probably on the wrong list.
>>>> I will try to get this a 'accessibility-ready' tag for my
>>>> theme although my first target will be to get my theme approved at all (
>>>> http://themes.trac.wordpress.org/ticket/15659).
>>>>
>>>> I read
>>>> http://make.wordpress.org/themes/guidelines/guidelines-accessibility/ and
>>>> find many don't but less howto or alternatives. I will give you an example,
>>>> i read "display:none removes the concealed object from screen reader’s
>>>> reading, and should not be used." I understand the meaning. Now
>>>> finding a good solution doesn't same easy. My theme use Twitter's
>>>> Bootstrap. Both Bootstrap and i paid attention to accessibility, see:
>>>> http://getbootstrap.com/getting-started/#accessibility and
>>>> https://github.com/bassjobsen/jamedo-bootstrap-start-theme/issues/35
>>>>
>>>> Although a default component the dropdown adds accessibility, see;
>>>> http://getbootstrap.com/components/#dropdowns it doesn't meet the
>>>> requirement of not using "display:none". Accessibility can be add by the
>>>> sr-only class and using aria-labelledby attributes, but there still will be
>>>> a "display:none".
>>>> In the case the dropdown adds additional information the content will
>>>> be hidden for all users. So maybe the requirement should be content with
>>>> "display:none" should be accessible for all users (for example also via a
>>>> sr-only button).
>>>> I also look for alternative solutions. You will find some here:
>>>> http://css-tricks.com/places-its-tempting-to-use-display-none-but-dont/.
>>>> Some solution requires javascript (or you show hide only when javascript is
>>>> on) which maybe introduce other accessibility issues.
>>>>
>>>> Regards,
>>>>
>>>> Bass
>>>>
>>>>
>>>> 2013/12/11 Joe Dolson <design at joedolson.com>
>>>>
>>>>> In addition to the fixed-layout, fluid-layout, and responsive-layout,
>>>>> the 'accessibility-ready' tag is going live in WP 3.8.
>>>>>
>>>>> For that tag, the guidelines at the theme accessibility review docs
>>>>> will need to be followed, in addition to the standard tags:
>>>>> http://make.wordpress.org/themes/guidelines/guidelines-accessibility/
>>>>>
>>>>> If anybody needs any help handling a review that's using the
>>>>> accessibility-ready tag, ping me with the ticket and I'll happily chime in.
>>>>>
>>>>> Best,
>>>>> Joe
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Dec 6, 2013 at 12:52 PM, Otto <otto at ottodestruct.com> wrote:
>>>>>
>>>>>> As part of the 3.8 release scheduled for next week, one of the
>>>>>> changes has to do with the allowed tags in themes.
>>>>>>
>>>>>> The old "Width" tags have been deprecated in favor of new "Layout"
>>>>>> tags, which are considered to better describe actual usage.
>>>>>>
>>>>>> - The "fixed-width" tag has become "fixed-layout".
>>>>>> - The "flexible-width" tag has become "fluid-layout".
>>>>>> - Finally, a new tag of "responsive-layout" was added.
>>>>>>
>>>>>> Currently, theme-check will fail these tags and disallow the upload.
>>>>>> As of 3.8's release, this will be changed to allow these new tags and to
>>>>>> give a warning about the old ones.
>>>>>>
>>>>>> With regards to theme searching, the old -width tags are aliased to
>>>>>> the new tags. So searching for "fixed-layout" will also find "fixed-width"
>>>>>> tags, and vice-versa. This is intended to not affect older themes or to
>>>>>> impact those themes ability to be searched for in any way, as well as to
>>>>>> allow themes using the new tags to continue to be found by pre-3.8
>>>>>> installations using the old tags.
>>>>>>
>>>>>> As I make this switchover, I'm sure there will be a few minor bugs
>>>>>> that crop up here and there. Some of those bugs will impact your ability to
>>>>>> upload themes. Let me know about any such issues directly and I'll correct
>>>>>> them as soon as possible.
>>>>>>
>>>>>> You can read more about the changes here:
>>>>>> http://core.trac.wordpress.org/ticket/21442<http://core.trac.wordpress.org/ticket/21442#comment:28>
>>>>>>
>>>>>> -Otto
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> theme-reviewers mailing list
>>>>>> theme-reviewers at lists.wordpress.org
>>>>>> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> ==================
>>>>> Joseph Dolson
>>>>> Accessibility consultant & WordPress developer
>>>>> http://www.joedolson.com
>>>>> http://profiles.wordpress.org/joedolson
>>>>>
>>>>> _______________________________________________
>>>>> theme-reviewers mailing list
>>>>> theme-reviewers at lists.wordpress.org
>>>>> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> theme-reviewers mailing list
>>>> theme-reviewers at lists.wordpress.org
>>>> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>>>>
>>>>
>>>
>>>
>>> --
>>> ==================
>>> Joseph Dolson
>>> Accessibility consultant & WordPress developer
>>> http://www.joedolson.com
>>> http://profiles.wordpress.org/joedolson
>>>
>>> _______________________________________________
>>> theme-reviewers mailing list
>>> theme-reviewers at lists.wordpress.org
>>> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>>>
>>>
>>
>> _______________________________________________
>> theme-reviewers mailing list
>> theme-reviewers at lists.wordpress.org
>> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>>
>>
>
>
> --
> ==================
>
> Did I help you with one of my plug-ins? Donations keep support possible!
> http://www.joedolson.com/donate.php
>
> ==================
>
> Joseph Dolson
> Accessibility consultant and WordPress developer
> http://www.joedolson.com
> http://profiles.wordpress.org/joedolson
>

-- 
==================
Joseph Dolson
Accessibility consultant & WordPress developer
http://www.joedolson.com
http://profiles.wordpress.org/joedolson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wordpress.org/pipermail/theme-reviewers/attachments/20140111/1fb12cce/attachment-0001.html>