Accessibility Team Meeting Agenda: 13 September 2019

This is the proposed agenda for the weekly 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) team meeting on Friday 13 September 2019 at 15:00 UTC.

If you have any additional topics to propose, please comment below.

The Accessibility bug scrub will be held on Friday 13 September 2019 at 14:00 UTC.

This meeting is held in the #accessibility channel in the Making WordPress 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/. (requires registration).

#5-3, #gutenberg, #twenty-twenty

Accessibility Team Meeting Agenda: 7 September 2019

This is the proposed agenda for the weekly 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) team meeting on Friday 7 September 2019 at 15:00 UTC.

  • Discussion about 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/ recent post: Defining Content Block Areas
  • Progress report on WordPress 5.3 TracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. tickets
  • WordPress 5.3: assign owners for tickets assigned to WordPress 5.3 milestone
  • Open floor

If you have any additional topics to propose, please comment below.

The Accessibility bug scrub will be held on Friday 7 September 2019 at 14:00 UTC.

This meeting is held in the #accessibility channel in the Making WordPress 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/. (requires registration).

#5-3, #gutenberg

Accessibility Team Meeting Notes: 2 August 2019

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/: Support Navigation and Edit Mode

For reference, see the related pull request on Gutenberg GitHub repository.

The idea is to use tabs key to provide a way to navigate between blocks with the keyboard (navigation mode). Hitting enter switch to edit mode (you can edit the 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. you navigated to). Hitting escape switch back to navigation mode.

All meeting attendees agree that this is a good improvement. It would be necessary to be extensively tested by as many persons as possible, including users of assistive technologies.

The next Gutenberg PluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party releaseRelease A release is the distribution of the final version of an application. A software release may be either public or private and generally constitutes the initial or new generation of a new or upgraded application. A release is preceded by the distribution of alpha and then beta versions of the software. is planned for August 12th. The 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) Team will publish a call for testers with some testing scenarios to test this big improvement.

Improving the Accessibility Team feedback on Gutenberg issues and pull requests

There is a need to follow Gutenberg development on both GitHubGitHub GitHub is a website that offers online implementation of git repositories that can can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ and 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/. (in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.-editor channel), and @afercia is currently spending a lot of time to follow it’s development, sending issues and reviewing pull requests.

As @afercia said: As of today there are 37 Gutenberg issues and pull requests with the “Needs Accessibility Feedback” label. The Accessibility Team need more persons able to follow that closely.

@nataliemac volunteered to help monitoring the “Needs Accessibility Feedback” label on Gutenberg GitHub Repository.

The Accessibility Team will discuss the possibility to find ways to have sponsored contributors (even a couple hours a week would be a great sponsorship!) during the next weekly meeting.

WP Accessibility Day – organizing team & next steps

Reminder: it was previously decided to evaluate the possibility to organize a dedicated WordPress global accessibility event, like polyglots do 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.

A couple of weeks ago, a spreadsheet was shared so Accessibility team contributors could sign up to be involved in this organizing team.

A dozen people signed up to the organizing team: @audrasjb, @joedolson, @nataliemac, @SergeyBiryukov, @bamadesigner, @gianwild, @bdeconinck, @jaymanpandya, @kevinbazira, @robin2go, @foucciano and @ryokuhi 🎉🎉🎉

The next step is to discuss the main focuses of the event and to divide the roles between the organizing team.

Feedback on Theme Review Team’s post about supporting keyboard navigation

For reference, see the related post drafted by @poena.

@audrasjb raised a missing item: focus order that should match visual order.

If a Web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability. (Level A)

Source: Web Content Accessibility Guidelines 2.0

@nataliemac added the post should include a warning about not relying on overuse of tabindex to accomplish this.

@afercia raised another item: there is a need to clarify that the native browsers outline can be removed but only if an alternative, like an accessible focus style, is provided.

@anevins: Theme authors should also be encouraged to use the Accessibility support forum if they get stuck.

Openfloor

During the next weekly meeting, the Accessibility Team will assign owners for the 53 tickets in the 5.3 milestone.

#5-3, #gutenberg, #wordpress-accessibility-day

Accessibility Team Meeting Notes: 26 July 2019

Meeting transcript on Slack

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.

For reference, see Make/Design blog post about Block Directory in WP-Admin Concepts and related GitHub Issues.

WordPress Design Team confirmed this design is meant to become the default for any future admin page.

The 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) Team raised some initial feedback for these early design:

  • The main h1 is not the first element within the main content area.
    “Add new”, search, help, and “mystery” menu are all above the h1. It’s important to get the heading before getting whatever tools are related to it. As these tools do change contextually, they are context-sensitive tools and headings are here to provide that context.
    When users land in a WP-Admin content area, they need an answer to the following questions: 1) What is this about? 2) What can I do here?
  • Center aligned multi-line text is problematic for low vision users. Given how little use of it there is, it’s not a huge concern: it’s only a problem in the text under the h1, as it causes low-vision users to have to hunt for the start of the next line. It’s not great, but it’s probably not a deal breaker, as it’s not primary content.
  • Icon-only controls:
    • The “more” button icon (three vertical dots) purpose is not very clear.
    • The current headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. implies that the user need to toggle the search to enable it, which is a new UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing. interaction for search.

The summary here is that the Accessibility Team have concerns about the header of these screens, which needs to be reconsidered in light of:

  • Proximity of controls
  • Giving context before tools
  • Use of icon-only controls

Note: @melchoyce shared an alternative design for the header of those screens after the meeting.

WordPress Accessibility Day – next steps

Reminder: it was previously decided to evaluate the possibility to organize a dedicated WordPress global accessibility event, like polyglots do 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.

First, we need an organizing team: about 10 people to evaluate deeply the feasibility and the scope of the project.

Contributors are welcome to add their name in this spreadsheet to signup to the organizing team. Then we can start organizing details and time frames. The group that plans what the event will be doesn’t necessarily have to be identical to the group that runs the event.

Usage of .screen-reader-text class in accessibility documentation

Theme Review Team contributors raised some concerns about the current screen-reader-text class documentation.

First, the way .screen-reader-text is documented is inconsistent – it’s a mix of saying “this is the CSSCSS CSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site. for .screen-reader-text” and “.screen-reader-text doesn’t need to be hidden”, and that’s contradictory. Accessibility people understand what it mean by that, but people being introduced to the concept don’t.

Instead of indicating that .screen-reader-text doesn’t need to be hidden, it would be better to say that this specific CSS is the required CSS for that class, and provide documentation on how to change the HTMLHTML HTML is an acronym for Hyper Text Markup Language. It is a markup language that is used in the development of web pages and websites.. The documentation should highlight the point of difference between visually hiding an element versus actually hiding it from the browser and accessible technology.

This will increase consistency with usage of .screen-reader-text – if somebody wants that text visible in a theme, then they can change the HTML; and it won’t be overridden by other plugins, etc.

Additionally, there’s some clarification required for the .screen-reader-text:focus CSS. The provided CSS will always set the focused objects into the skip-link position, but that may not be appropriate if the theme author is not styling skip-links. The document should indicate clearly that if focused screen reader text is not a skip-link, the positional elements of this need to be changed.

@joedolson is going to take care of rewriting the related docs and will work with @joyously to ensure the new documentation is clear enough for theme authors and WordPress developers.

Open floor

@nataliemac is looking for volunteers who will be at WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. US to be teaching assistants in a 2-hour accessibility workshop. They will be leading up to 100 attendees through some general accessibility concepts and testing and fixing accessibility issues on their own websites.

@poena: in only a few weeks time theme authors will be required to support keyboard navigation. The Theme Review Team is going to publish a post to help them prepare.Accessibility Team contributors are welcome to read the public draft and to share any concerns by pinging @poena on accessibility 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 or by commenting this Make/Accessibility post.

#documentation, #gutenberg, #wordpress-accessibility-day

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 releaseRelease A release is the distribution of the final version of an application. A software release may be either public or private and generally constitutes the initial or new generation of a new or upgraded application. A release is preceded by the distribution of alpha and then beta versions of the software. 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

Accessibility of Gutenberg, the state of play

TL;DR

How accessible is 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/ in its current state (version 2.4)? To answer this the 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) team set up a list of minimum requirement, did code reviews and research, gave recommendations and set up user tests.

The short answer is:

  • Gutenberg still needs extensive work to meet basic standards, like keyboard accessibility and semantics
  • Especially for screen reader users, Gutenberg as it stands right now is a dramatic step back in usability
  • We need to write a manual/documentation for assistive technologyAssistive technology Assistive technology is an umbrella term that includes assistive, adaptive, and rehabilitative devices for people with disabilities and also includes the process used in selecting, locating, and using them. Assistive technology promotes greater independence by enabling people to perform tasks that they were formerly unable to accomplish, or had great difficulty accomplishing, by providing enhancements to, or changing methods of interacting with, the technology needed to accomplish such tasks. https://en.wikipedia.org/wiki/Assistive_technology users

From the start

During development, almost from the start, Andrea Fercia (@afercia) did extensive 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) (accessibility) testing and research. He and others created issues labeled accessibility on GitHubGitHub GitHub is a website that offers online implementation of git repositories that can can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ to address the issues found (Andrea created more than 50 of them).

At the moment 70 a11y issues are open, 166 are closed. A lot has been addressed, but there are still very important issues open (like for keyboard accessibility, tab order and navigation).

User testing

When Gutenberg 2.3 was released, Tammie Lister (@karmatosed) considered it ready enough for a complete accessibility test.

We wrote a user test, that includes the basic functionality needed to publish a post. Like add a title, headings, paragraphs, a list, a table an image and a video, use the 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. options and publish.

On our testserver wpaccess.org we installed the pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party, version 2.3, and gave our a11y test team access. Joe Dolson also recruited accessibility experts for a test of version 2.4 at the CSUN conference. All results are reported in the Google spreadsheet Gutenberg a11y test results.

So far we’ve got good quality test results for

  • Keyboard only
  • Dragon Naturally Speaking
  • VoiceOver / Safari
  • NVDA / Firefox

Andrea created new GitHub issues from the reported problems or added extra information with the already reported ones.

Videos with user tests

Note: These users (Eric Wright and Sina Bahram) are leading accessibility experts, using their assistive technology on a daily basis and using WordPress for their work.

 

Minimum requirements before merge

To set a baseline, what should be fixed before merge we set up a list of requirements:

  1. Keyboard navigation through blocks needs to be greatly simplified and streamlined
  2. For some components, there’s the need to constrain tabbing within the component (i.e. they should behave like “modals”)
  3. The publishing flow needs to be simplified, currently its accessibility is terrible
  4. Everything needs to live inside the landmark regions
  5. Text mode: a simple textarea is the only guarantee to enable users to publish content, regardless of the device / technology they use
  6. Write documentation for keyboard and screen reader users.
  7. Consider a mechanism to customize shortcuts, e.g. Cmd/Ctrl + backtick, see issue #3218
  8. Block toolbars position counter intuitive for keyboard users, see issue #3976
  9. The Date picker must be keyboard accessible

Severe issues

One of the most severe issue is the keyboard accessibility. The keyboard tab order is unpredictable. The tab order for and backwards is not the same. Publishing a post is a puzzle and the date picker is unreachable with a keyboard only.

Another issue is the need for quick navigation tools, like shortcuts and better use of landmarks and headings. There are so much more actions to take for adding or modifying a block. Compared to the current classic editor, publishing a post with a screen reader takes much more time and effort.

Because the extensive use of icons, voice recognition users have to guess the accessible names for buttons to activate them. This needs a design decision.

Actions to take

  • Fixing the keyboard accessibility and screen reader navigation is a high priority. Andrea opened issues for this and we need to prioritize these
  • At WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. London and Europe we will do extra user testing with assistive technology and discuss the results with Tammie Lister and the Gutenberg developers present
  • The accessibility team needs to take responsibility for the manuals and documentation. This documents only can be written after the minimum requirements as listed above are met

#accessibility-usertest, #gutenberg

Amanda’s Thoughts On “Gutenberg and the WordPress of Tomorrow”

Good post by Amanda Rush (@arush), about the need for good documentation and manuals for 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/ users.

Thoughts On “Gutenberg and the WordPress of Tomorrow”

#gutenberg

Screen reader user experience with Gutenberg

The last weeks we let the WPA11y test team try out 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/.

Responses

Working with blocks takes some getting used to. I don’t like it when the editor takes over the way I work this way. Can I switch this off? I see now that there is a link in the list table: “Classic editor”. This should be easier to find.
I can imagine blocks will be useful in some cases. The future will tell.

While selecting and copying text in the blocks strange things happen. The cursor gets lost and I have to click the mouse to return into the text.

With the 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. settings the user can select colours for text and background. It would be useful to have the name visible on hover. This will be useful for colourblind people.

User of JAWS/IE: There is way to much going on and far too many menus to deal with. With the current version I can hit the f key 3 times and get to the Title, now it takes 3 times as much if I manage to land on it after trying to add something. I find it very difficult to accomplish anything because of the many menus and options. Please let the option for the “Classic editor” stay.

User of NVDA/FF56: Well I doodled with the editor, the best thing about it, well there isn’t, I guess the heading where the title should be is nice.
The rest, I was able to add a block of text, typing it up but the publish menu I couldn’t exactly navigate, I preferred the button as it was.

There are a lot of buttons a lot unlabeled. I found Gutenberg full of clutter, buttons and the like.

Wrapping this up

Blind screen reader users have a hard time navigating and figuring out how things work. That’s understandable, all users have that issue while they learn the new interface. But Gutenberg is a much worse user experience for them, lots more buttons to click and actions to take for the same task. A way to help them may be keeping the option for the classic editor.

I think we started too soon testing Gutenberg with the wpa11y test team. Most of them kind of broke down on Gutenberg and don’t want to take the energy to test anymore. Lesson learned for next time.

Thanks Geoff Collis, Wim Moons and Shaun Everiss for testing.

#gutenberg

Test results accessibility Gutenberg, July 6, 2017

In this post we gathered testing results for the new text editor 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/. 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 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) test team to look at the pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party. Below are the reported 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) 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.comWordPress.com An online implementation of WordPress code that lets you immediately access a new WordPress environment to publish your content. WordPress.com is a private company owned by Automattic that hosts the largest multisite in the world. This is arguably the best place to start blogging if you have never touched WordPress before. https://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 technologyAssistive technology Assistive technology is an umbrella term that includes assistive, adaptive, and rehabilitative devices for people with disabilities and also includes the process used in selecting, locating, and using them. Assistive technology promotes greater independence by enabling people to perform tasks that they were formerly unable to accomplish, or had great difficulty accomplishing, by providing enhancements to, or changing methods of interacting with, the technology needed to accomplish such tasks. https://en.wikipedia.org/wiki/Assistive_technology:
  • 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. 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 PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. http://php.net/manual/en/intro-whatis.php. code directly. It’s so cool
  • Display latest post via Widgets is too easy
  • Add all HTMLHTML HTML is an acronym for Hyper Text Markup Language. It is a markup language that is used in the development of web pages and websites. 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

Revising the WordPress Editor: Gutenberg and Accessibility

One of the three top priorities for development in the next releases of WordPress is to enhance and modernize the editor. This is an important project to give users the ability to create rich and diverse content without requiring extensive knowledge of code. From an 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) perspective, this is both an incredible opportunity to build a powerful and flexible experience for all users and an enormous risk that we could end up reducing the effectiveness of the editor for users with disabilities, or require them to use a 2nd-class editor without these enhanced editing capabilities.

We in the WordPress accessibility community embrace the challenge of creating a great new experience, and want to assure the community that we are going to do everything we can to make sure that any new editor experience is as accessible as we can possibly make it.

The most fundamental part of democratizing publishing is the ability to write and publish content. Without that feature, WordPress is not achieving its coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. mission. There are always challenges in creating content accessibly, but it is not an unachievable goal.

It’s still early in the process, and there are many ideas floating around about how the new editing experience should be structured and how its interface should behave. The concerns for accessibility are universal, however. The new editor should consider accessibility to be a priority both in how content is created and in the nature of the content that is created.

While the accessibility team wants the final implementation to be exceptional and accessible, we don’t want to limit the possibilities by imposing restrictions before they are necessary. However, there are some concepts that should be kept in mind early on that will significantly impact accessibility during development.

Fundamentals of Accessibility to Consider

  1. Some common user interface interactions are extremely difficult to use non-visually. Drag and drop is an interaction that poses significant difficulties, since it is very difficult to disclose in audio how the dragged object and the potential targets are interacting. This doesn’t mean that the editor can’t use these interactions, but if they are used, there will need to be an alternative method to do the same task which is accessible.
  2. Fundamentally, all outputted code is organized in a linear manner. The experience of the content for keyboard users and for screen reader users will also always be linear. Ensuring that the content authoring process encourages a linear path will make the process easier for all users.
  3. Whenever possible, the user interface should encourage people to create semantically valid code; encouraging the use of correct headings (e.g., being content aware to know which headings are valid for a new content 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.); encouraging the addition of alt attributes, or defining table headings appropriately for tabular data.

Updating the editor is a great opportunity to explore some of the requirements articulated in the Authoring Tool Accessibility Guidelines (ATAG). These requirements discuss how an editor should allow users to navigate the structure of their content and how the editor should encourage the creation of accessible content. A richer editor experience, with integrated prompts and formatting tools, has the potential to suggest best practices throughout the content authoring process. This would be an important growth step for WordPress.

It should be self-evident that the new editor experience needs to meet the standards established for accessibility in WordPress core. The editor is the central experience of WordPress content creation, so planning ways to consider accessibility at every stage through the process is crucial to the success of the Editor project.

Help develop the new editor

If you’re interested in helping with the new Editor project, follow the development conversations in #core-editor and share your thoughts and ideas. You can also follow the GitHub project for the editor, where you can file tickets or follow specific issues like keyboard shortcuts, drag and drop, and the mobile interface. Weekly chats are in #core-editor, Wednesdays at 18:00 UTC.

#gutenberg