Community Conduct Project – Kick off meeting scheduled for 17:00 UTC on the 5th September 2017

Community Conduct Project – Kick off meeting scheduled for 17:00 UTC on the 5th September 2017

This week in WordPress Accessibility, August 14th, 2017

Transcript of the meeting

Handbook

The work for rewriting and reorganising the Handbook is in progress: @samikeijonen, @travel_girl and @rianrietveld are writing the first topics, @joedolson is reviewing them. We plan to write at least one topic per week. And the deadline for the first iteration of handbook is March 1, 2018. We enjoy the discussions on Slack: writing everything down makes us really think about what the best practices are.

SelectWoo

We send the SelectWoo demo pages to the testers for assistive technology testing and hope to get feedback this week. The testers will add their findings to the Github issue Review SelectWoo accessibility.

Codemirror for WP 4.9

Because the addition of Codemirror is planned for WP 4.9, we started the discussion with ticket #12423 again. On GitHub it’s available as a plugin, so we’ve opened an issue with our concerns of a code highlighter as default text editor. It’s not accessible for screen reader users. The plugin is also installed on our test server at wpaccess.org/codemirror/ for user testing if needed.

Gutenberg

We installed Gutenberg, from Git Master, on our test server and asked testers to test again, the first test we did was a few months ago and a lot has changed in the meantime. The results are collected and published by @karmatosed on GitHub, labeled feedback.

The next test should be a review of the output of all blocks on the frontend.

Next meeting

  • The next meeting will be at August 28, because too many people are on holiday the 21st.
  • On every Thursday we will informally discuss the handbook during the day.

Thanks @samikeijonen @travel_girl @joedolson @arush @nicbertino @zakkath @karmatosed @sergeybiryukov for joining the discussions.

#weekly-meetings

This week in WPA11y – July 24, 2017

Transcript of meeting.

The discussion of the handbook was punted to the July 31st, 2017 meeting, as @samikeijonen was unable to attend this week’s meeting. As this discussion was originally intended as the primary focus of this week’s meeting, the entire meeting was open floor, with no agenda.

Topics discussed

Gutenberg: block output

@afercia recommended we set up a test to review the output of all Gutenberg content blocks, as many of the new block types generate different output than the equivalent in the existing editor, such as the image gallery block.

@rianrietveld requested that @afercia create a post for testing that contains all relevant options.

We determined that we need to first perform an expert review of the general issues, request modifications as necessary, then gather user feedback once any major errors have been worked through.

The team briefly discussed the reasoning behind creating content blocks that generate features that exist in the current WordPress ecosystem using different output HTML; further conversation on this topic should probably land in relevant Gutenberg issues.

Gutenberg: user testing

@nicbertino volunteered to manage moderated user testing for Gutenberg, to start with general user testing, then proceed to specific testing with users requiring assistive technology.

#weekly-meetings

This week in WPA11y – July 10, 2017

We talked about five topics in our weekly meeting:

  1. How to process test results for Gutenberg.
  2. New Handbook topics.
  3. Project managing a11y tickets in trac.
  4. Windows High Contrast mode.
  5. Open floor.

We tried Slack Threads for the first time. Each topic was in it’s own thread. It was mostly confusing and you can’t put images or code snippets in the thread. Good thing is that afterwards it’s easier (at least for me) to follow discussions.

It’s worth noting that Devon Persing and Scott Vinkle joined our meeting. They work in a team called Simply Accessible.

Here are short summaries about discussions.

How to process test results for Gutenberg

First Gutenberg test results are full of data. Andrea Fercia have filtered the report and I’ll post issues in Github. We also agreed to follow accessibility label in Github. We should know at least the titles of the accessibility issues. Unfortunately most of the team members doesn’t have enough time to contribute on Gutenberg.

It’s also important to create more specific tests with simple tasks like

  • keyboard navigation.
  • focus management.
  • navigating between different parts.
  • screen reader text issues.

New Handbook topics

We have started gathering topics to new accessibility handbook. The idea is to educate others by writing summaries of different topics and collect good resources of them. For now ideas are in Google Sheet, let me know if you have more topics in mind or want to help out in any other way.

Project managing a11y tickets in trac

Trac can be overwhelming even if looking info from Trac Handbook. Therefore Morten Rand-Hendriksen pulled data from CSV export into Google Sheet. We are exploring would that help

  • to get a quick overview of what’s happening.
  • see what tickets new contributors should focus on.
  • see who is involved and what the status is.

We are not sure yet how to make use of this and Morten will look into it more. For example could it be automated.

 Windows High Contrast mode

High contrast mode benefit users with low vision or people working in dark environments. More information can be found in two places:

  1. Comment in Gutenberg issue.
  2. Focus style and High Contrast Mode Trac ticket.

This is not issue only in Gutenberg but in WordPress admin in general.

Open floor

We talked about food, what else 🙂

#weekly-meetings

Test results accessibility Gutenberg, July 6, 2017

In this post we gathered testing results for the new text editor Gutenberg.
As the functionality is work in progress, we will use these test results to create issues and add to the discussion on GitHub.
If you wrote a blogpost about this or published test results in another way, please add this as comment to this post, or tweet it to WPAccessibility. Then we’ll add it to the list of blog posts with testdata.

In this post:

  • Results WPa11y test team
  • Blogposts with test data and research
  • Call to action

Results WPa11y test team July 6th 2017

Thanks to: Janki Moradiya, Riddhi Mehta, Shah Rishi, Geof Collis, Gabriela Nino de Rivera, Reagan Lynch, Shaun Everiss

We asked the accessibility test team to look at the plugin. Below are the reported a11y related experiences and issues:

General opinion:

Reagan: My first and initial impression, and yes I understand this is early testing, is that Gutenberg is a major change and major step backward in WP accessibility. I strongly encourage the WordPress development team to NOT put this as the default editor. If you want to force it then do so on wordpress.com, but give us a choice with the .org (self-hosted) version. Gutenberg as it currently stands will force me to consider other platforms. In fact, after giving up on the second blog post I opened a Ghost account for the first time ever and began learning how their system works. If Gutenberg becomes the default Ghost will be the more accessible platform. (Using Windows 10 with Firefox and JAWS for Windows.)

Geof: To put it mildly, I don’t like it, it is too complicated and busy. I found it easier to add an image and move it around with in the main body if necessary, using a screen reader there are too many actions to deal with, I hope they drop the idea. (Using IE 11.096, JAWS 11 with latest updates, Windows 7.)

Shaun: I think in general, as long as you never need to change styles, add lists of media or ever interact with the button panels, then you should be fine. So what if you have to? You just can’t [Editor: mild translation of the original text]. (Using Win7 Pro, NVDA, Firefox)

What is a better experience

Without assistive technology:

  • Block arrangement and easily adding blocks on the post
  • Embedded any video or clip is too easy.So, now add media it’s not tedious anymore
  • The main part is code option is we can add the shortcodes and other PHP code directly. It’s so cool
  • Display latest post via Widgets is too easy
  • Add all HTML element easily and mainly add and other tags which are very interesting.
  • Easily move blocks with the up-down errors is too useful
  • The look and feel of the visual editor are good and it is very easy to manage content and I think it’s time-saving for development.

What is worse

Without assistive technology:

  • Aligning blocks and makes clicking into content areas are problematic.
  • Having a whole section for Embeds of only tangential use seems clumsy.
  • When I publish the post there is not a “VIEW” button available for that post edit screen of Gutenberg.
  • If writing something in the text block and click on undo button it was removing the whole section instead of new word or sentence.

If I select any text from the content block then it’s selected the whole block for delete so, it’s considered my selection as deleting a block. For batter understanding, I have captured a video for the same.

With VoiceOver + Safari:
It was very difficult to navigate between blocks and options for formatting. If I have more than 2 blocks moving from one block to the other is a long way. I need to pass through each menu and button associated to the block. It is very tiring. Also, accessing options in the menus don’t respond well to VoiceOver commands. I was often redirected to other places in the page like “post settings” or “skip to main content” link.

The insert button it was not intuitive, it took me a while before finding how to insert a block image.

Insert link options buttons (enter, edit and erase) does not seem to have labels. VoiceOver announces them only like “button”.

When inserting a link, if I don’t type a URL address beginning with http://, Voiceover announces that the data is invalid. The insert link object keeps announcing “Enter a URL” like if any text were already typed. There is not a proper message to explain the user why the data is invalid or a placeholder (or something else) to show the expected input format.

What is impossible to do

Without assistive technology:

I think in current version changing the post format is impossible.

Not able to move “Separator” when blocks structure are typical. For better understanding, I have captured a video for the same.

There is always a placeholder “Write…” with text box it’s become confusing to add new block and it consumes one block space as well. For better understanding, I have captured a video for the same.

I have created a table and added data into it. Later I add the table in the same post the table will create with old table data automatically. If I delete the table from the post and later I add the table it will comes with the last data of the table.

With VoiceOver + Safari:
When editing text in a block, it is better to select an option in a menu before writing content. If text is already in the block, it is not possible to select it and then select an option in the menu to apply a format (like for example select a list, or bold or italic). I think it would be nice to have shortcuts for applying format without quitting the block. Something like selecting text and then using a shortcut for applying the desired format without having to navigate all the elements between the block and the menus.

Settings button does nothing when clicking on it.

With Windows 10 with Firefox and JAWS for Windows.

The post screen does not have a very intuitive layout. In visual mode the buttons to edit do not appear until after I begin to add content. I’m unclear on how or if I can change the level one heading for the title.

When I tab from the title field to what should be the content area I think I was adding a line of content. Upon pressing enter to start a new paragraph I was taken out of forms mode and completely lost on the page for a few minutes. I should not be taken out of forms mode in a content body text area type field.

I changed to the text mode, and while typing content was easier when I attempted to select text to make a link I saw no field to add a link like is currently present with the editor in 4.8.

At one point when I selected text to make a link and then pressed enter on the link button in text mode text I had entered disappeared. From reviews I’ve read it seems there are buttons that appear when I first enter a “block”, but using a screen reader I don’t know what those are.

I like to write blog posts and page content outside of WordPress using an editor like Jarte. When I copied text out of Jarte in this test and went to paste it the experience was terrible. I cannot paste without losing all formatting. I also don’t understand “blocks”. Using TinyMCE I feel like I’m in a very accessible environment. With Gutenberg I want to stop blogging.

ON the Gutenberg page it says, “The goal of the block editor is to make adding rich content to WordPress simple and enjoyable.” Well I hate to say it, but as a power user of WordPress it makes adding rich content more complex for me.

I wrote two blog posts, or tried. With the first I used my normal copy editing process and had the post done and ready to go within an hour. WithGutenberg I was still trying to format the text correctly two hours later and had missing content that just disappeared. I gave up in frustration over the process

What don’t you understand

Without assistive technology:
I did not understand the work or use of the first button in post settings panel.
Toggle button in the settings panel

I found that in text editor all top buttons/tags are not working properly and when I click on them or out site the text editor “” and “” added automatically and it looks very confusing for me.

I did not find how to add the new row or new column in table format.

Blogposts with test data and research

If you wrote a blogpost about this or published test results in another way, please add this as comment to this post, or tweet it to WPAccessibility.

June 2017

Juli 2017

Other lists

Call to action

If you wrote a blogpost about this or published test results in another way, please add this as comment to this post, or tweet it to WPAccessibility.

If you want help testing and fixing? please read Help needed from accessibility experts with the development of Gutenberg.

#accessibility-usertest, #gutenberg

This week in WPA11y – June 27, 2017

WordCamp Europe

For discussions and plans see: Takeaways from Paris.

New structure handbook

We agreed on the following new structure: Per topic short explanations, then links to good articles and examples. The resources do not need to be WordPress specific.
We’ll need some method for ensuring the currency and accuracy of resources listed, if we’re going to list specific resources. So probably restrict the resources to the most authoritative ones. And we need to check the resources regularly.

Order of things:

  • make a list of topics
  • add an intro per topic
  • add resources to it

@samikeijonen and @rianrietveld will start with a spreadsheet gathering the topics, everyone can add possible resources to that later, so we can see what we can use for the handbook.

Test Gutenberg

Now Gutenberg is available as plugin we want to install it on our test server and give it to the test team this week. With a clear description on what it does and a link to the issues already reported on GitHub.

@arush already gave her review: Gutenberg With A Screen Reader: Initial Thoughts And Reactions

Adjustments Accessibility Coding Standards

@joedolson is working on a new draft, work in progress.

New Settings API

The plugin Settings API enhanced is now an almost complete prototype, but still needs refinements and design. It’s a prototype though, many things could change. We would like feedback from more people before moving on.

And what else happend

Next meetings

Next New Setting API meeting: July 3 ,2017 at 16:00 UTC in the Slack #core channel
Next WPa11y meeting: July 3, 2017 at 17:00 UTC in the Slack #accessibility channel.

#weekly-meetings

Takeaways from Paris

So the community summit, the contributor day and WordCamp Europe happened in Paris. And this is what we learned from all the discussions we had during that warm week in June:

Education instead of taking over

The accessibility team must not try to do everything themselves. Like raise and solve all accessibility trac tickets themselves. What we should do is add to the tickets how they should be solved and let other developers do the patches (or ask them to do). Hopefully this will attract more developers to do accessibility tickets. That way the developers will learn instead of handover to us. Now the team is like a proxy, everything needs to go though us, slowing the process down. What we need to accomplish is that the developers solve the issues themselves, and we just help them if needed.

Handbook

The handbook must be replaced by a list of resources, good examples and test tools, with short explanations. We don’t need to write everything ourselves, but make list of links with a short intro per subject. Focus on education and point to good info. In other words: help and educate the developers instead of fixing ourselves.

Testing and research

We need to ask more a11y experts from outside the WordPress community to assist us with the testing and research. For this we can reach out to companies specialised in accessibility, ask them if they can sponsor time to do research on WP core and featured projects.

So this defines 3 tasks for the a11y team

  • Teach: Provide easy to use overview of resources for developers
  • Research: Test and research current and new functionality for accessibility
  • Help: Review and raise accessibility tickets and provide developers with info on how to solve the issues

This doesn’t mean we won’t be working on tickets and issues on GitHub, we want to move our team focus to research, education and support.

This week in WPA11y – June 5, 2017

WordCamp Europe

Topics Community Summit (CS):

  • New developments for the the Editor, and how to safeguard it’s accessibility – (Core)
  • Technology version support policies – (Core)
  • How to involve more developers in helping with the accessibility tickets
  • How to proceed with the handbook
  • Addition: Considering the shift towards JS-based interfaces, we should consider to review and update the accessibility coding standards

@joedolson will write up a draft for the updated coding standards, for us to discuss on the CS.

Contributor day:
All plans are in the Google Doc: List of goals for Contributors day in WCEU.
And the is also a list of a11y tickets to pick from.

Testing

After June 26th we will start testing again. For this patches and plugins will be installed on our test server and given to the test team.

To test:

Next meetings

There won’t be a meeting or bug scrub on June 12th (due to WordCamp Europe).

 

#accessibility-team-meetup

X posting Proposal WordPress Community Conduct Project

X-posting Proposal: WordPress Community Conduct Project
Please read + comment on the original post.

Proposal: WordPress Community Conduct Project

X-post: Nearby WordPress Events

Hello! Looking for feedback: https://make.wordpress.org/core/2017/04/14/nearby-wordpress-events/