Accessibility Team Meeting Notes: 19 July 2019

Meeting transcript on Slack

GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ experiments settings page

The feedback needed is on the settings page: has it been implemented as recommended? See related Gutenberg GitHub pull request for reference. That page is going to appear under the Gutenberg admin menu.

@karmatosed gave some backstory:
Today, if you wanted to try or test these features you would have to add code in the console. This is not a great way forward. It excludes and it makes testing really problematic. That’s what the pull request looks like, in release this doesn’t exist yet. What feedback is needed, is if the pull request implements the settings page as expected for accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility).

@afercia: one problem of the Settings APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. with regards to checkboxes is that the checkbox labels needs to be placed on the right of the checkbox. I also think it’ll help to have a short description under each option that explains a little more about what each option is. Of course, that leads to duplication of the bold text on the left and real elements, but that’s a historical problem.

Couple years ago we experimented improved Settings API, proposing to not use the two columns layout. That would solve a lot of problems but needs design. And it’s a bit out of the current scope. An improved WordPress Settings API with default render callbacks and a new accessible layout.

@nrqsnchz: In terms of a11yAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility), I’m thinking this each group should be marked up as a fieldset? What does everyone else think?

@afercia gave a code example: Discussion settings:

<tr>
    <th scope="row">Email me whenever</th>
    <td>
        <fieldset>
            <legend class="screen-reader-text"><span>Email me whenever</span></legend>
            <label for="comments_notify">
                <input name="comments_notify" type="checkbox" id="comments_notify" value="1" checked="checked">
                 Anyone posts a comment
             </label><br>

            <label for="moderation_notify">
                <input name="moderation_notify" type="checkbox" id="moderation_notify" value="1" checked="checked">
                A comment is held for moderation
            </label>
        </fieldset>
    </td>
</tr>

@karmatosed: If that’s going to be the recommend way let’s ship it.

WordPress Accessibility Day

Context: last week, it was decided to evaluate the possibility to organize a dedicated WordPress Global Accessibility Event, like polyglots did with WordPress Translation Day (WPTD). The idea is to organize a 24-hour virtual event all around the world with some video conferences and focused on contributing to WordPress accessibility.

To organize such an event, the accessibility team needs at least 10 organizers and some support from other teams. That would be interesting to connect with WPTD organizers.

@ryokuhi: Last week we decided to leave a week so that everyone could check their possible involvement. I don’t know how are other local slackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel organized, but (at least in Italy) we have a dedicated local channel for a11y. How about asking people involved in accessibility in their local communities, but not in the Make/WordPress general accessibility Slack channel, to take part in the Accessibility Day organization?

@afercia: Maybe the first step would be pinging persons from different countries and ask this question.

We identified this page as a list of the local communities Slacks: https://make.wordpress.org/polyglots/handbook/about/teams/local-slacks/ That would be great to have some feedback to know if that list is up to date.

@sami.keijonen to ask in Finnish Slack Group. @audrasjb to ask in French Slack Group. @karmatosed to ask in UK Slack Group.

There is a public Google Document to share ideas on the event organization.

Next week agenda items

@afercia proposed one Agenda item for next meeting: BlockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. Directory in WordPress Admin.

During WCEU’s Summer Update, Matt presented a new wp-admin section for Blocks. @afercia want to share those early concepts during next Accessibility Team Meeting. In the meantime, please have a look at Block Directory in WP-Admin Concepts Make/Design blog post and the related GitHub Issues.

#gutenberg, #wordpress-accessibility-day