Experiment: Move unselected block accessibility handling to block-holder #937

Tug · 2019-04-26T18:02:43Z

Alternative to #936
Gutenberg PR WordPress/gutenberg#15225

This PR moves accessibility handling of unselected blocks to the BlockHolder

It updates e2e tests as well which were broken with this updates (we rely on the accessibility label to find blocks).

Testing Instructions

Try navigating blocks on Android with Talkback on
Try navigating blocks on iOS with VoiceOver on

For instance:

An heading block should have all the following information spoken:
"Heading Block. Row X. . Button"
A paragraph block should have all the following information spoken:
"Paragraph Block. Row X. . Button"
An empty image block should have all the following information spoken:
"Image Block. Row X. Empty. Button"
A non-empty image block with a caption should have all the following information spoken:
"Image Block. Row X. . Button"

peril-wordpress-mobile · 2019-04-26T18:02:46Z

	Warnings
⚠️	PR is missing at least one label.
⚠️	PR is not assigned to a milestone.

Generated by 🚫 dangerJS

etoledom

Looks and works great, nice job @Tug ! 🎉

I added a few comments, mostly ideas/questions.
cc @JavonDavis . I wonder how this could impact UITests, but they seems to be passing anyway ✅

etoledom · 2019-04-29T09:52:38Z

src/block-management/block-holder.js

+
+		if ( name === getUnregisteredTypeHandlerName() ) { // is the block unrecognized?
+			return title; //already localized
+		}


We could add an accessibility label to missing/index.js, in a way that VoiceOver can tell the type of block:
i.e: "Unsupported block. Gallery", "Unsupported block. Unknown"

I don't mean to add accessibility labels to missing block on this PR, but just saying that it might not need an special handling.

etoledom · 2019-04-29T09:59:02Z

src/block-management/block-holder.js

+		const blockType = getBlockType( name );
+		if ( blockType.getAccessibilityLabel ) {
+			const blockAccessibilityLabel = blockType.getAccessibilityLabel( attributes ) || '';
+			return blockName + ( blockAccessibilityLabel ? '. ' + blockAccessibilityLabel : '' );


I like that this give us a good default label.
I was thinking if it's worth it to return the whole sentence from the block's blockType.getAccessibilityLabel directly (including the "{Block Name} block..." part, and construct this default just when blockType.getAccessibilityLabel is not implemented.

This could make sentences easier to localize, could give us more flexibility if it's needed, but it also could be more error prone (someone could forget to add the "{Block Name} block." at the beginning).

Do you think that this approach would be beneficial?

I am aiming towards to the current approach because it brings consistency. With this, the description for all blocks starts with 'X block. '

on the other hand I think the '. ' and concatenations needs a revisit as we discussed earlier for localization issues. would it be better to do this as follows?

sprintf( /* translators: accessibility text. 1: block name. 2: block content information. */ _x( '%1$s block. %2$s', 'Accessibility text for a block' ), blockName, blockAccessibilityLabel );

JavonDavis · 2019-05-01T20:40:22Z

src/block-management/block-holder.js

@@ -206,8 +229,9 @@ export class BlockHolder extends React.Component<PropsType, StateType> {
 			// accessible prop needs to be false to access children
 			// https://facebook.github.io/react-native/docs/accessibility#accessible-ios-android
 			<TouchableWithoutFeedback
-				accessible={ false }
-				accessibilityLabel="block-container"
+				accessible={ ! isSelected }


I like this, it makes more sense to only make it false when it's selected and we'll only interact with the inner elements when it's selected anyway

Yes, it doesn't seem to work on android though...

JavonDavis · 2019-05-01T20:44:54Z

I wonder how this could impact UITests

It shouldn't and didn't 🙂Since the TouchableWithoutFeedback is set to false when the block is selected, the tests should continue as they are.

etoledom · 2019-05-02T15:03:52Z

As a note: This PR fixes #14, #910 and (probably) #950

…ected-accessibility-use-settings

etoledom

Looks great - @Tug ! 🎉

I think we still can improve how the unsupported block is handled, but as we talked, this is a step solution into a one more robust.

I'd like to experiment having this kind of labeling for the unsupported block:

https://github.com/WordPress/gutenberg/blob/fb577f5119da59c4c6423fc897b0437b6725f2de/packages/block-library/src/missing/edit.native.js#L30

But I believe we can do it on a separated PR.

etoledom · 2019-05-22T09:49:19Z

src/block-management/block-holder.js

+
+		const blockName = sprintf(
+			/* translators: accessibility text. %s: block name. */
+			_x( '%1$s block' ),


Should this be __ instead of _x?
And since there's just one variable, %d should be enough?

…e accessibility attribute

* Include Node debug option for IntelliJ

JavonDavis

The comments I left along with the changed behavior of getAccessibilityLabel I think are causing the iOS tests to fail on CI... I branched off onto to #1041 to test this out and the tests pass on CI for iOS there, I think the getAccessibilityExtra call isn't working as expected.

JavonDavis · 2019-05-28T22:56:14Z

src/block-management/block-holder.js

 				<View style={ [ styles.blockHolder, borderStyle, { borderColor } ] }>
 					{ this.props.showTitle && this.renderBlockTitle() }
 					<View
-						accessibile={ true }
+						accessible={ ! isSelected }


Is there a specific reason this is here and not on the TouchableWithoutFeedback? That's the container whose accessibility value would need to be changed to allow inner elements to be accessible

Yeah I wanted to basically group all the accessibility props together and View already had the accessibilityLabel prop.
The idea is that both TouchableWithoutFeedback and the View are containers of our block so both have the potential to be accessible elements. I did some test and I'm not sure it changes things much where we put it.

I did some test and I'm not sure it changes things much where we put it.

Oh, I played around with it too and could've sworn it was affecting some things for me but I was playing with a few things and I don't remember for certain, let me try again and see if I can reproduce again here

JavonDavis · 2019-05-28T23:00:50Z

src/block-management/block-holder.js

 						accessibilityLabel={ accessibilityLabel }
+						accessibilityRole={ 'button' }


We're forcing the inner container here to be treated like a button, was there an additional benefit of this? It's already surrounded by a Touchable which I think's enough

This is only meant for the screenreader. Adding accessibilityRole={ 'button' } will translate to the screenreader saying "button" at after reading the accessibilityLabel. Meaning the user can interact on it like a normal button (ouble tap to select the block in this case)

Hey @Tug 👋 I tested this and currently it is not saying "button" after reading accessibilityLabel. But when I move accessibilityRole={ 'button' } to TouchableWithoutFeedback level it does say it:

<TouchableWithoutFeedback onPress={ this.onFocus } accessible={ ! isSelected } accessibilityRole={ 'button' } >

So we might want to update this like that.

Indeed it does that on iOS when the block is unselected. I was able to confirm that moving accessibilityRole="button" to TouchableWithoutFeedback fixes it on both platforms. However, I also I noticed that it says "button" first before reading the view's accessibility label on Android so I moved everything to TouchableWithoutFeedback and now it works as expected!

It looks like CI tests are failing this time. I have an idea, we can just set an accessibilityHint rather than an accessibilityRole and keep the accessibilityLabel where it was.

<TouchableWithoutFeedback onPress={ this.onFocus } accessible={ ! isSelected } accessibilityHint={ __('Double tap to focus') } > <View style={ [ styles.blockHolder, borderStyle, { borderColor } ] }> { this.props.showTitle && this.renderBlockTitle() } <View accessibilityLabel={ accessibilityLabel }

Another option would be ofc updating the CI tests according to the current settings

Tried to debug the e2e tests but as I was wasting too much time on this I ended up reverting the change in this commit.
I guess it's not too critical to have "button" mentioned before the accessibility label on android. We have many improvements to do on accessibility anyway.
@pinarol could you give it a final check please :)?

At least the issue is resolved on iOS, now I hear: "Paragraph block. Row n. Text. Button" 👍 Thanks

…und errors

Tug · 2019-05-29T11:36:59Z

I think the getAccessibilityExtra call isn't working as expected.

This would be annoying because it's the main change of this PR. I've checked again and it seems to be working. Could you expand on what's not working here?

Anyway it's green now thanks to your commit a55b735 Thanks a lot @JavonDavis 🙇

@etoledom @pinarol Could you give it a try now?

JavonDavis · 2019-05-31T22:14:53Z

This would be annoying because it's the main change of this PR. I've checked again and it seems to be working. Could you expand on what's not working here?

@Tug Sorry for taking a little while to clarify what I meant here... When I was testing this locally and running the e2e tests the code in the if ( getAccessibilityLabelExtra ) { statement was being executed and from my understanding of the comment above that line it shouldn't(?) and that's what caused the need for the new XPath using contains? removing that like I did in #1041 I was able to go back to the = instead, I'm going to test this again to be sure...

pinarol

I tested the PR and it seems OK overall. Just one thing: the accessibilityRole is not read. I added a comment about it in the related line. After fixing that I think we are good to go.

…ected-accessibility-use-settings

JavonDavis · 2019-06-03T20:18:34Z

I'm going to test this again to be sure...

@Tug My bad, it seems the issue I was seeing was related to something else, getAccessibilityLabelExtra works as expected! 👍

…ected-accessibility-use-settings

pinarol

LGTM! 🎉

…ected-accessibility-use-settings

pinarol and others added 9 commits April 25, 2019 16:56

Update gutenberg ref

433d8c8

Update gutenberg ref

92b55a4

Update gutenberg ref

acf87e8

Update gutenberg ref

e7a7e14

Add unselected block accessibility

764581f

Move block unselected state accessibility handling to block-holder

f487087

Update gutenberg ref

f8b3f2c

Merge branch 'develop' into issue/update-unselected-accessibility

76fe327

Add getAccessibilityLabel to block settings

81450c6

Tug self-assigned this Apr 26, 2019

Tug mentioned this pull request Apr 26, 2019

[Mobile] Move unselected block accessibility handling to block-holder (v2) WordPress/gutenberg#15225

Merged

etoledom reviewed Apr 29, 2019

View reviewed changes

JavonDavis reviewed May 1, 2019

View reviewed changes

Tug added 6 commits May 15, 2019 18:31

Update gb ref and use __experimentalGetAccessibilityLabel

7f3dcb3

Merge remote-tracking branch 'origin/develop' into issue/update-unsel…

d3294f7

…ected-accessibility-use-settings

Update gutenberg ref

8d7ebda

Update gutenberg ref

e83fde4

Update gutenberg ref

f9daad9

Fix type def in BlockHolder

fbeba8c

etoledom self-requested a review May 21, 2019 12:38

etoledom approved these changes May 21, 2019

View reviewed changes

etoledom reviewed May 22, 2019

View reviewed changes

pinarol mentioned this pull request May 23, 2019

Move unselected block accessibility handling to block-holder #936

Closed

11 tasks

Tug added 4 commits May 23, 2019 15:01

Update gutenberg ref

4bbd25b

Update gutenberg ref

95166be

Handle setting UnrecognizedBlock accessibility label in BlockHolder

3199fab

Handle setting UnrecognizedBlock accessibility label in BlockHolder

1d752c9

Tug and others added 6 commits May 28, 2019 13:51

Fix lint errors

4c7809c

Make sure the block attributes have updated before searching using th…

db6a23a

…e accessibility attribute

Handle case where no blockType is found

a781649

Revert unnecessary changes to e2e

4cb4ad7

Update e2e test descriptions

4400544

* Use deepest element when retrieving block

a55b735

* Include Node debug option for IntelliJ

JavonDavis mentioned this pull request May 29, 2019

Try/remove extra accessibility attributes #1041

Closed

JavonDavis reviewed May 29, 2019

View reviewed changes

Tug added 4 commits May 29, 2019 12:46

Use element.sendKeys instead of element.type to avoid Keyboard not fo…

ac1efc5

…und errors

Move accessible prop to TouchableWithoutFeedback

ec967ea

Revert to using type

a39aef6

Fix lint error

8ba8904

pinarol reviewed Jun 3, 2019

View reviewed changes

Tug added 4 commits June 3, 2019 14:09

Move all accessibility props to TouchableWithoutFeedback

ef0a086

Update gutenberg ref

a036757

Merge remote-tracking branch 'origin/develop' into issue/update-unsel…

0436928

…ected-accessibility-use-settings

Merge remote-tracking branch 'origin/develop' into issue/update-unsel…

121b7d8

…ected-accessibility-use-settings

Tug added 3 commits June 5, 2019 14:31

Have accessibilityLabel prop in the View to fix e2e tests

ab3f0a3

Update gutenberg ref

ab049ed

Merge remote-tracking branch 'origin/develop' into issue/update-unsel…

01320c3

…ected-accessibility-use-settings

pinarol approved these changes Jun 6, 2019

View reviewed changes

Tug added 2 commits June 6, 2019 14:14

Update gutenberg ref after merge

47aeee4

Merge remote-tracking branch 'origin/develop' into issue/update-unsel…

2077aac

…ected-accessibility-use-settings

Tug merged commit 936b474 into develop Jun 6, 2019

Tug deleted the issue/update-unselected-accessibility-use-settings branch June 6, 2019 12:50

etoledom mentioned this pull request Jun 6, 2019

[Mobile] Modified More block to be read-only WordPress/gutenberg#16005

Merged

etoledom mentioned this pull request Jul 10, 2019

Improve Screen Reader support for Separator block. #910

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Experiment: Move unselected block accessibility handling to block-holder #937

Experiment: Move unselected block accessibility handling to block-holder #937

Tug commented Apr 26, 2019 •

edited

Loading

peril-wordpress-mobile bot commented Apr 26, 2019

etoledom left a comment •

edited

Loading

etoledom Apr 29, 2019

etoledom Apr 29, 2019

etoledom Apr 29, 2019

pinarol May 16, 2019

JavonDavis May 1, 2019

Tug May 16, 2019

JavonDavis commented May 1, 2019

etoledom commented May 2, 2019

etoledom left a comment

etoledom May 22, 2019

JavonDavis left a comment

JavonDavis May 28, 2019

Tug May 29, 2019

JavonDavis May 31, 2019

JavonDavis May 28, 2019

Tug May 29, 2019

pinarol Jun 3, 2019

Tug Jun 3, 2019

pinarol Jun 3, 2019

pinarol Jun 3, 2019

Tug Jun 5, 2019

pinarol Jun 6, 2019

Tug commented May 29, 2019

JavonDavis commented May 31, 2019 •

edited

Loading

pinarol left a comment

JavonDavis commented Jun 3, 2019

pinarol left a comment

		accessibilityLabel={ accessibilityLabel }
		accessibilityRole={ 'button' }

Experiment: Move unselected block accessibility handling to block-holder #937

Experiment: Move unselected block accessibility handling to block-holder #937

Conversation

Tug commented Apr 26, 2019 • edited Loading

Testing Instructions

peril-wordpress-mobile bot commented Apr 26, 2019

etoledom left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

JavonDavis commented May 1, 2019

etoledom commented May 2, 2019

etoledom left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

JavonDavis left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Tug commented May 29, 2019

JavonDavis commented May 31, 2019 • edited Loading

pinarol left a comment

Choose a reason for hiding this comment

JavonDavis commented Jun 3, 2019

pinarol left a comment

Choose a reason for hiding this comment

Tug commented Apr 26, 2019 •

edited

Loading

etoledom left a comment •

edited

Loading

JavonDavis commented May 31, 2019 •

edited

Loading