WordPress.org

Make WordPress Accessible

Updates from October, 2014 Toggle Comment Threads | Keyboard Shortcuts

  • Joseph Karr O'Connor 11:21 pm on October 26, 2014 Permalink  

    Accessibility Resources 

    Information and Tools

    Many people have asked us for accessibility information. Information is readily available from several sources. WebAIM has a wealth of information about accessibility, and the mailing list is especially good. At accessiblejoe.com you will find a list of accessibility checking tools and some info about adding content to WordPress sites in an accessible manner.

    Rules of the Road

    While Section 508 is often referred to as the rules of the accessibility road in the USA, it is sorely outdated. A 508 refresh is underway. The rest of the world uses the W3C Web Content Accessibility Guidelines version 2.0 (WCAG 2.0). The 508 refresh will bring it into synchronization with WCAG 2.0, so if your orders are to adhere to 508, you’ll be ahead of the curve if you refer to WCAG 2.0. The WordPress accessibility team refers to WCAG 2.0 and we test to level AA. There are some very good resources by the W3C to explain WCAG. But before you look at the guidelines or success criteria there are some principles to keep in mind first.

    Understanding the Four Principles of Accessibility: Perceivable, Operable, Understandable, and Robust (POUR)

    The following principals are from the WC3 Understanding WCAG 2.0:

    The guidelines and Success Criteria are organized around the following four principles, which lay the foundation necessary for anyone to access and use Web content. Anyone who wants to use the Web must have content that is:

    1. Perceivable – Content is perceivable through sight, hearing, and touch and is transformable in multiple ways. For example, text (sight) can be transformed into audio by using a screen reader (hearing) and into braille using a refreshable braille display (touch).
    2. Operable – User interface components, navigation, and content must be navigable or operable using various input methods like screen readers, voice navigation, braille keyboards or even just your left thumb.
    3. Understandable – Information and the operation of user interface must be understandable by all. Did you declare the language in the doctype statement so screen readers and text-to-speech produce proper pronunciation? Are you explaining jargon and acronyms?
    4. Robust – Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies. Some people even use a sip and puff tube with alternate interfaces..

    Getting Help

    Contact us by using the pathways on our Get Involved page.

     
  • Rian Rietveld 9:42 am on October 21, 2014 Permalink
    Tags:   

    Accessibility testing of the Twenty Fifteen theme 

    This week the new theme Twenty Fifteen was placed into trunk, so we could take a look at it.

    We discussed the issues found in the replies with @davidakennedy‘s post: Time to Test Twenty Fifteen! and in our testing session last Monday.

    Here’s a summary of what we found and the follow up on that (we assigned people to post tickets on this).

    The order is in order of priority.

    1. Heading structure

    To our opinion multiply H1’s are not a good way to set up the heading structure.
    Our suggestion:
    One H1 per page. This is the site title for the home page, the page of post title for a single page or the archive title for an archive. The rest of the content should be meaningful devided into h2/h3/h4 etc headings.
    An improvement that can be easily made is change the H1’s for the widget titles into a H2 in functions.php.
    Ticket: @davidakennedy #30065

    2. Menus

    The main menu works good with keyboard only, also with a submenu.
    But with a screen reader it gives problems and the structure isn’t read well.
    This may need some study to do it properly
    Ticket: @davidakennedy #30083

    3. Search form

    In the current HTML of the search widget form there is no proper relation between the label and the input field. The input should have an ID and the label a for= to the ID.
    Also the submit button has class with display: none; That should be a class screen reader only.
    Ticket: @rianrietveld #30110

    4. Thumbnail link

    The thumbnail of a post in archives are placed inside a link to the post itself.
    The alt text is the alt of the image, this can result in a link text that makes no sense.
    Screen reader users want to know what’s on the image, but don’t want to lose context on where the link is going.
    There are different ways to solve this, as we can see in ticket #15926 and #28861
    Maybe finding a solution here could also be a solution for #15926
    Ticket: @rianrietveld #30076

    5. Sidebar is placed above the content

    We decided that that’s ok.
    There is a skip to content link for keyboard and screen reader users, that should be sufficient.
    The toggle on the sidebar should have a slightly different screen reader support.
    Ticket: @bramd

    6. Background images next-prev links should be darker

    Ticket: @davidakennedy #30069

    7. Underline links on hover

    Underline menu links and post links in archive on hover to make it more clear they are a link
    Ticket: @katherinemancuso #30108

    8. Site description

    The site description should not be defined as an H2 heading. It is not a section or content title.
    We suggest placing it inside a p element.
    Ticket: @rianrietveld #30057

    9. 404 template Text: “Maybe try one of the links below”.

    This may be old text that needs to be updated
    Ticket: @davidakennedy #30061

    Further commenting and work we will do in the tickets on the trac as they are posted.

    This list of issues is not complete. If you find other accessibility issues? Please reply to this or @davidakennedy‘s post: Time to Test Twenty Fifteen!

    A big thanks to @davidakennedy, @nsousa, @bramd, @katherinemancuso, @arush, @sharonaustin for testing.

     
    • Badeyes 1:28 pm on October 21, 2014 Permalink | Log in to Reply

      Hi Rian

      My thoughts:

      I’ve always been of the opinion that there should be only 1 H1 per page as you’ve decided and that the sidebars should be ahead of the content, as Web Aim screen reader surveys read, us screen reader users dont use them very often if at all.

      I’d rather have an H2 heading to get to it with an ARIA Landmark and label such as global navigation or page navigation.

      cheers

      Geof
      p.s. I’m not sure who created this form but I almost clicked reply before I realized there were 2 checkboxes for getting replies to this thread, someone might want to look into fixing that for us screen reader users if it is possible. :O)

      • Rian Rietveld 9:28 am on October 22, 2014 Permalink | Log in to Reply

        Hi Geof,
        Thanks for your input. I find it always difficult to track how all the different screen reader users navigate and to get the HTML in a good working order for everyone.

      • MRWweb 4:12 pm on October 22, 2014 Permalink | Log in to Reply

        Geof, one of the Web AIM screen reader survey results that has always caught my eye is [the majority preference for **two** H1 tags per page](http://webaim.org/projects/screenreadersurvey3/#headings), one for the site name and one for the title. I’m not a screen reader user myself, but I could imagine that might be especially helpful for site entrances onto pages other than the home page. Is this something that should be considered instead of a single h1 based on that survey result?

    • David A. Kennedy 4:26 am on October 22, 2014 Permalink | Log in to Reply

      I added the tickets assigned to me, along with some patches.

      Heading structure: Ticket by @bramd and first patch by @davidakennedy. #30065

      Background images next-prev links should be darker: Ticket and first patch by @davidakennedy. #30069

      404 template Text: “Maybe try one of the links below”: Ticket and first patch by @davidakennedy. #30061

    • MRWweb 4:16 pm on October 22, 2014 Permalink | Log in to Reply

      I don’t know that this is the moment or place to tackle this but I wanted to point out that both points 1 and 7, heading structures and site description, respectively, are what I’m guessing are “up stream” problems coming from the underscores theme. It would be really nice if this work could find its way into underscores as those are two of my biggest pet peeves about that theme!

    • David A. Kennedy 2:28 pm on October 23, 2014 Permalink | Log in to Reply

      I’ve filed a ticket for the Menu issue:

      Ticket #30083.

      cc: @rianrietveld @bramd

    • Rian Rietveld 3:22 pm on October 23, 2014 Permalink | Log in to Reply

      Thanks David!

    • Chuck Reynolds 11:06 pm on October 26, 2014 Permalink | Log in to Reply

      Is this not a good time to discuss the theme header title and subtitle being H1 and H2 respectively? I think it’s fine for those to be that way on the blog root or homepage, but on single posts and pages the title of the post/page is the H1, and should be… the header h1/h2 should revert down into non-headings imo; and most of the themes I build.

      So on top of the sidebar headings and stuff being knocked down, which also make sense – the header thing should be considered or at least discussed.

      Thx

  • Jen 6:29 pm on October 20, 2014 Permalink
    Tags: ,   

    WCSF Final Planning 

    If you are not attending WCSF this year, you can ignore this post. If you are coming and planning to participate as part of the accessibility team, please click through and read it all. 🙂

    (More …)

     
  • Trisha Salas 7:24 pm on October 15, 2014 Permalink  

    Accessibility/UI Collaboration on Posts/Pages Screen 

    There are several tickets open that relate directly to accessibility in the content editing experience on the posts/pages screen (see this post by Joe Dolson for details). Since Avryl is currently working on the editor this is a good time to discuss combining efforts to work on accessibility/UI for the posts/pages screen as well. With combined efforts we could create a revised/improved UI for the posts/pages screen while taking accessibility into account during the entire process.

    • Change the UI to create an intuitive post/page creation experience for the user
    • We can possibly use parts of CEUX for this
    • The UI should be built with a focus on Accessibility first
    • Minimize or eliminate the need for documentation
    • Collaboration with Avryl will ensure that any changes to the editor will be taken into account when creating a new UI.

    This was discussed some in the Accessibility meeting on 10/8 (link).  Avryl mentioned she could use some feedback on the inline tools plugin when it’s ready (link).

    The kick-off meeting is currently scheduled for UTC Thursday, October 16, 2014 at 8:00 PM.  If anyone would like to be involved in this project, please join us.  I scheduled the meeting time based on best times for UTC to Central US time zone.  Please feel free to comment if you would like to attend but are unable due to the time.

    We have the potential to make some very impactful and beneficial changes both in terms of usability and accessibility.

     
    • nsousa 9:04 am on October 16, 2014 Permalink | Log in to Reply

      Hi,

      Id like to be envolved in the project.
      I’m afraid I cannot participate in the meeting.
      But I’m available by e-mail.

      Regards,
      NS

  • David A. Kennedy 2:42 am on October 15, 2014 Permalink
    Tags:   

    Time to Test Twenty Fifteen! 

    Today, Twenty Fifteen landed in /trunk.

    @iamtakashi and others have worked really hard to make this first pass accessibility-ready from the start. 🙂

    I’ve done an initial accessibility-ready review and advised on a few bug fixes. But we still should bang and bend this lovely theme from an accessibility perspective.

    Note: This theme has different color schemes, so keep in mind only the default one needs to meet the accessibility checks.

    We’d love to find a more elegant solution for the focus styles on the main navigation links.

    If you’re not comfortable filing a ticket, just comment here and we’ll consolidate them into feedback on future tickets.

    Please post all feedback here. If you are using assistive technology to test Twenty Fifteen, please indicate exactly what software you are using and web browser — including the version number, if possible.

    To test Twenty Fifteen:

    1. Install WordPress locally.
    2. Download and install the Beta Tester plugin.
    3. Configure the Beta Tester plugin and update WordPress.
    4. Activate Twenty Fifteen and test to these standards.

    October 15, 2014: Updated post with instructions on how to get Twenty Fifteen. Updated with additional feedback instructions.

     
    • Rian Rietveld 8:56 am on October 15, 2014 Permalink | Log in to Reply

      I suggest we use next test meeting to look at Twenty Fifteen together.
      That will be on Monday October 20 from 17:00 UTC on IRC #wordpress-ui

    • nsousa 10:10 am on October 15, 2014 Permalink | Log in to Reply

      Hi,

      I’d like to test the theme. How can I do it?
      Is the theme for download: changeset_29892.zip? Can I import it to wordpress 4.0? If not, how can I access the twenty-fifteen theme?
      I use screen-readers. I tried to follow the information in:
      https://core.trac.wordpress.org/changeset/29892
      but didn’t got it!

      Some clues are welcome.
      Regards,
      NSousa

    • Sharon Austin 7:12 pm on October 15, 2014 Permalink | Log in to Reply

      Congratulations on a beautiful, beautiful gorgeous new theme. The hard work is obvious, and really appreciated.

      Even more appreciated is how everyone is working together to ensure an accessible theme.

      One thing that jumped out at me immediately, however, is the visual confusion that results from having a header image behind the default menu. I can tab to all the items, but I can’t see them visually because the background “clutters” the visual landscape.

      Also, as is noted in ticket #15926, there is no way to add alt tags to the header image.

      Beautiful theme, guys and gals!

    • Sharon Austin 8:22 pm on October 15, 2014 Permalink | Log in to Reply

      Here’s a link to an example pageshow you what I’m talking about regarding visual clutter.

      But I want to emphasize that I think this is a BEAUTIFUL theme! Thanks again! 🙂

      • David A. Kennedy 11:51 pm on October 16, 2014 Permalink | Log in to Reply

        That’s a good point Sharon, but there is an option in the Customizer that allows users to change the text color for the Header and Sidebar. So depending on the image, users can change things.

        In this case, at least, adding alt text is less of an issue because the image is added via CSS as a background. So hopefully, users understand these images should really only be decorative and not content.

        • Sharon Austin 12:30 pm on October 17, 2014 Permalink | Log in to Reply

          “In this case, at least, adding alt text is less of an issue because the image is added via CSS as a background.”

          ….in that case, then, sir THAT….is outstanding! 🙂

    • Bram Duvigneau 9:04 am on October 16, 2014 Permalink | Log in to Reply

      Just had a first quick look with a screenreader. I’m not sure if putting all the navigation before the content in code order is a good idea. Yes, I know there is a skip to content link and that’s good, but not everyone will use that.

      • David A. Kennedy 12:19 am on October 17, 2014 Permalink | Log in to Reply

        Hey Bram,

        Thanks for your thoughts!

        How would that be different than having the navigation toward the top of the page, like in any other theme? Is it because the optional sidebar is below the main navigation?

    • nsousa 2:25 pm on October 20, 2014 Permalink | Log in to Reply

      Hello David,

      I agree with Bram. It would be better if sidebar comes after the content in the code. My comments about Twenty Fifteen theme below.
      I already have some comments about Dashboard pages, but I promise I’ll try to make a new ticket!

      Homepage issues

      • The heading description should not be defined as heading. It is not a section or content title;
      • Sections/widgets titles: Recent posts/ articles should be H2;
      • Main content title should be H2;
      • Link Cancel reply should not be heading; [Please check the E-mail I sent about headings.]
      • Navigation role: complementary information should involve all the widgets from the sidebar and not each widget. It is too much noise to a screen reader user!
      • Widget titles shouldn’t be written in capital letters.
      • Few contrast. By default

      there should be a higher contrast.

      Suggestions

      • Assume the menu name as the role navigation title. In dashboard menus page give this information to the admin/editor; [In the future it could be also made available to other roles, e.g. Sidebar or extra menus.]
      • Put main content before sidebar in the code; [If you’ve many widgets in the sidebar the user that uses heading navigation quick key will take a lot of time to achieve the main content.]
      • Include a link before the sidebar – or even before each widget- to jump it;
      • Include a link to turn to top of the page at the end of the main content;
      • include an accessibility menu to choose contrast, colour and increase/decrease zoom.

      See examples:
      http://iact.ipleiria.pt/en/

      my site in portuguese:
      http://www.comacesso.pt

      I’ll back if I’ve more issues or suggestions.
      Regards,
      NSousa

      • Rian Rietveld 3:21 pm on October 20, 2014 Permalink | Log in to Reply

        Hi @nsousa,
        To my opion the H1 should be the post/page/archive title and only on the homepage be the site-title, to avoid that all pages have the same H1, agree on the heading description, that’s no heading.

        Why shouldn’t the Widget titles be written in capital letters?

        Where is the contrast to few?

        I disagree that an accessibility menu should be added, to my option the theme is already good for contrast and colour, and because the font sizes are relative, a Ctr+/Ctr- works perfectly.

      • KatherineMancuso 5:25 pm on October 20, 2014 Permalink | Log in to Reply

        I agree with @rianrietveld on the accessibility menu point. An accessibility menu including the features @nsousa wants (color, contrast, zoom) can currently be added to any theme by using the WP Accessibility plugin (https://wordpress.org/plugins/wp-accessibility/) by Joe Dolson.

        While it would be interesting to have it be native in the theme, this would be asking for a major change to the theme which probably won’t be able to be implemented in time for release. Also, this feature reflects WCAG 2.0 compliance at the AAA level, and the accessibility laws in most countries request AA compliance. Therefore, this represents a “nice to have” but not an essential for most accessible sites, and should be a lower priority in terms of feature requests than issues which relate to AA compliance.

    • Rian Rietveld 3:01 pm on October 20, 2014 Permalink | Log in to Reply

      Hi All,

      Hereby my a11y testing results of Twenty Fifteen, also @bramd did a screen reader check.
      Haven’t got solutions for everything, but plan to open or add to tickets after the IRC test session today (Oct 20, 2014, 19:00 UTC)

      Tested the nightly build WordPress 4.1-alpha-20141019.
      Tested against WCAG 2 AA guidelines and WordPress a11y guidelines.
      Also did W3C validator checks.

      This test is not complete, just did what I had time for. today So If you see more, please comment.

      First of all, WOW, what a beautiful theme!

      Love the details and like the way next previous posts are done and keyboard usability of the sub menu’s and also the social media menu. And it shows that there was efford to get a11y done right.

      Ok, here it is, Issues found:

      Heading structure:
      This is a really big disappointment, an overload of H1’s that leads to an HTML outline that makes no sense al all.
      Yes, it is all HTML5 compliant, but is also in heavy dispute for more than a year now, see for example:
      http://www.paciellogroup.com/blog/2013/10/html5-document-outline/
      This means: one H1 per page and the rest meaninghull devided into h2/h3/h4 etc headings.

      To my opinion this is a path that we must not go.
      At least change the widgets to an H2 in functions.php
      I agree with @nsousa, this should be done semantically correct.
      Also: make the tagline not a h2 but a p, it’s not a heading of any content whatsoever.
      And: add an H2 before a nanigation with, for example, the menu titel.

      Keyboard accessibility:
      Focus:dotted line, that’s OK
      A link with an image insidet gets no dotted line on focus in Safari, maybe add in CSS something like
      a:focus, a:focus img {
      outline: thin dotted;
      }

      W3C validation of HTML:
      As expected:
      “Consider using the h1 element as a top-level heading only (all h1 elements are treated as top-level headings by many screen readers and other tools).”

      W3C validation of CSS:
      The validator only complains about new CSS3 functionallity, not an issue for accessibility to my opinion.
      Like width and height calc don’t parse (yet).

      Colour contrast:
      Colours of the default theme are all WCAG 2 AA compliant as far as checked

      Menu’s:
      The main menu works good with keyboard only, also with a submenu.
      But with a screen reader it gives problems and the structure is’t read well.
      Button is block element, can’t be placed inside an inline element such as a.
      The text inside the button is expanded or collapse, but it’s not clear what is expanded or collapsed.
      Needs another workaround for screen reader.
      suggestion: underline menu links on hover to make it more clear they are clickable.

      Next -previous:
      The background of this link is the featured image of the post, which is nice, when the image is too white, the text can’t be read properly.
      Suggestion:
      .post-navigation .has-post-thumbnail a::before
      background-color: rgba(0, 0, 0, 0.6);

      Sidebar:
      It’s already said in comments above, and I agree, putting the sidebar before the content seems weird and not usable.
      The toggle on the sidebar is’t very clear for screen reader users
      Here the use of expanded/collapse is appropriate.

      Header Image:
      Header image is in fact an overall body background image
      How to properly add a logo or such?

      Search form:
      A label has to have a for to the ID of the input field.
      The submit button has class display: none; why?
      Is there any use for adding the submit? because this way it isn’t displayed in any device or AT.
      There is a title=”Search for:” in the input field. Why? It doesn’t improve accessibility at all.

      My suggestion:
      label for=”search-field” class="screen-reader-text">Search for:</label
      input type="search" id=”search-field” class="search-field" placeholder="Search …" value="" name="s">

      404 template:
      Text: “Maybe try one of the links below”.
      What links?

      Archive template:
      The thumbnail alt text is image alt, should be post title.

      Comments template:
      Done correctly in the theme, but not in default WP, so maybe no issue here
      If there is no comment the “Leave a Reply is a H3 (default WP), for there is one ore more comments the comments title is an H2 (which is correct).

      For me, the biggest issue is the heading structure.

      • nsousa 4:54 pm on October 20, 2014 Permalink | Log in to Reply

        Hi,

        Capital letters are more difficult to read by persons with reading difficulties and low vision.
        Besides that, if you read a word in capital letters with screen reader in a foreign language – and for some cases even in the sites’ language – it will spell the word instead of reading it normally.
        At least, make capital letters through CSS.
        Yes, the theme is well done, but we can improve it more!
        Ctrl + plus is known by you and by me, but there’s still many people who doesn’t know it.
        Bram wrote:
        add an H2 bevore a vanigation with for example the menu titel.

        It is not used anymore because there is role navigation.
        Headings should be used for sections structure and not for navigation.

        Good meeting,
        NSousa

        • Rian Rietveld 6:37 pm on October 20, 2014 Permalink | Log in to Reply

          Capital letters are made in the CSS here, so screen readers don’t have trouble with it, the HTML is lower case.

          I’m not screen reader expert, but @bramd is, so I leave you two to fight over the navigation heading issue 🙂

      • KatherineMancuso 5:15 pm on October 20, 2014 Permalink | Log in to Reply

        I agree with Rian that it is essential to fix the heading structure. In particular, there will be major benefits for both SEO & accessibility if there is only one H1 per page.

    • nsousa 10:01 pm on October 20, 2014 Permalink | Log in to Reply

      Hello,

      Rian wrote:
      “To my opion the H1 should be the post/page/archive title and only on the homepage be the site-title, to avoid that all pages have the same H1,”
      NS. Comments about headings below. I sent it by E-mail before participating in the group discussion.
      I also agree with you, but you should not make a front page structure different from the other pages.

      Bram wrote:
      “Header Image:
      Header image is in fact an overall body background image
      How to properly add a logo or such?”
      NS. I’ve also the same question.

      My comments about headings:
      Regarding heading’s hierarchy I’ll try to explain it better.
      At the moment, site, page and articles titles are defined as H1.
      The sections’ titles, E.g. Categories; activities; etc. are defined as
      H3. So it brokes the hierarchy.

      Suggestion 1:

      • Leave Site’s title as H1 and Define page, articles and sections title as H2.

      Suggestion 2:

      • Remove heading from Site’s title; leave page title as H1; define

      articles’ and Sections titles as H2.

      Suggestion 3:

      • Remove heading from Site’s title; leave page title as H1; create a

      new content title defined as H2; define articles’ as H3; Sections
      titles as H2.

      In the future, it would be great if we could offer an option – very
      important to the Non-coders developers – to choose if this new content
      title should be hidden or not and to choose one of the hierarchies
      proposed above.

      Issue 2 – site’s Description defined as H2 and hidden
      In twenty-thirteen the Site’s title is defined as H1: Ok;
      Description is defined as H2: there’s no need to be a heading, since
      it is not a content/section’s title.

      In twenty-fourteen even if it is chosen not to be displayed, screen
      readers read both site’s title and description. Besides that,
      Description is read not just after site’s title as in twenty-fourteen

      • but almost at the end of the page.”

      Good Work,
      NS

      • Rian Rietveld 10:06 am on October 21, 2014 Permalink | Log in to Reply

        Hi @nsousa,

        Thanks for your feedback!

        To my opinion the H1 should be what’s the page is about, so, the post title for a post for example. Leaving the site title as H1 results in the same H1 for every page on a website and I think that not semantic right and also bad for accessibility and SEO.

        Kind regards,
        Rian

    • Andrea Fercia 11:37 pm on October 20, 2014 Permalink | Log in to Reply

      Hi, I’m very interested in this point from @nsousa:

      > Navigation role: complementary information should involve all the widgets from the sidebar and not each widget. It is too much noise to a screen reader user!

      I’ve noticed this using NVDA and pressing “d” to navigate through ARIA landmarks and yes, it’s very annoying. It would be great to have some feedback and user testing on this specific issue. To test, just remember to have a bunch of widgets in your sidebar 🙂

      With NVDA you can also get a list of ARIA landmarks in a page pressing NVDA key + F7 which will open an “Elements list” popup with 3 lists: Links, Headings, Landmarks.

      This is something that is used not only on Twenty Fifteen but comes from the starter theme _s (or underscores) so it would be a very important change also for the next default themes.

      About ARIA landmarks, see as reference:
      http://www.paciellogroup.com/blog/2013/02/using-wai-aria-landmarks-2013/
      where there’s a clear example of a WordPress theme with just 1 complementary region.
      See also the structure of Bruce Lawson’s site mentioned in the article:
      http://www.brucelawson.co.uk

  • David A. Kennedy 1:20 am on October 15, 2014 Permalink  

    Accessibility Team Update: October 8, 2014 

    Here’s our team update for the week:

    • We’re continuing our weekly testing meeting. Be sure you note the time in the sidebar, if you’re interested in participated.
    • We now have the Handbook plugin activated on our site and work has begun to create an Accessibility Handbook. Contact @davidakennedy if you’d like to help.
    • @trishasalas is working on tutorials for the accessibility-ready theme tag.
    • We discussed #29838 and how it might fit into some other work going on in Core.

     

     
c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel
Skip to toolbar