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.

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
		);

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...

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

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

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