Rob Campbell [:rc] (:robcee) Reporter
	Description • 10 years ago

Markup view entries are currently not accessible. Unable to view attribute names, possibly other entries in the markup panel.

	Marco Zehe (:MarcoZ)
	Comment 1 • 10 years ago

Without these, the view is not usable with a screen reader. Bumping priority.

	Athena Assignee
	Comment 2 • 10 years ago

Code-wise, this is not up to scratch (please ignore that it's not properly localized!), but I'd like to request feedback on approach and make sure this is headed in the right direction.


(1) Using VoiceOver with tab: When moving through the markup view pane, the elements aren't read out loud and they need to be given an aria-label. But the open and close angled brackets aren't read while passing through. So, for example, this code:

    <div class="foo">long text here etc</div>

Is read as:

    "div"
    "class=foo"
    "long text here etc"


In the patch above, there's some additional description, making it more like this:

    "div tag"
    "class=foo attribute"
    "long text here etc text content"

--> Is the bare bones form preferred, or the more verbose one?


(2) Using VoiceOver with VO + arrow keys: reads out items differently from just using tab. Before changes, the above is read as: 

    "less", "div", "space", "class", "equals", "foo", "quote", "greater"

After changes the above is read as:

    "less", "div tag", "space", "class equals foo attribute", "greater"

This is close to how (1) is read, but with additional punctuation marks.


(3) Adding the aria-label made the text visible, but there's no indication that these are editable and it feels like that's an important part of the markup view. I can see two possible ways of looking at this:

(3a) labels + text fields is the more standard combination, but the text fields are hidden until you switch to them by activating the label so what I've gone with instead is (3b)

(3b) each tag name or attribute is a button that, when activated, reveals a hidden text field

--> Is there any strong reason to choose (3a), or is there otherwise a standard good way of handling this pattern? 

TBH, I'm more familiar with things the other way around: label hidden, input visible.

	Athena Assignee
	Comment 3 • 10 years ago

* rebased onto more recent HEAD for easier review (patch failing to apply)
* removed unnecessary change handler

	Marco Zehe (:MarcoZ)
	Comment 4 • 10 years ago

Comment on attachment 8462540 [details] [diff] [review]
add aria label + button role to markup view

Welcome to the craziness that is the world of different speech synthesizer and punctuation settings! :-) The short story is: You can't know which setting the user might have, and if the angle brackets are read by the individual speech synthesizer they're using, or not.

So the safest bet is to go with something like:

"div tag, class blah, ID bleh, role something, ..."

e. g. be explicit about what is the tag, and give the attribute names and their values, all items separated by commas. Commas cause virtually all screen readers to pause, giving users structure while they listen to the information.

And I think having these as buttons, with Space to activate/expand, is fine. You could add an aria-expanded set to true of expanded, false if collapsed, to the individual "buttons" so the user immediately knows if the current item is expanded or not. And change that value upon expansion or collapsing.

	Athena Assignee
	Comment 5 • 10 years ago

Sounds like fun!

Double-checking: what I'm working on right now is specifically for the case when someone is tabbing through the markup view. Each item in the markup view currently has a tabindex of 0, which means they get the tag name then the attribute names one at a time as they hit tab. (Currently on a mac, nothing is read, on windows something generic is read, "text frame"?)

Your advice to use commas seems to be more for the case when someone is navigating through the markup using the screenreader navigation and not tab, so that each item is read as one long block of code. 

Do we also want a separate aria-label for this case, including commas to provide structure, or should I just concentrate on making the tabbed items comprehensible?

	Marco Zehe (:MarcoZ)
	Comment 6 • 10 years ago

Ideally, the items one lands on with tab are the same one navigates to with VoiceOver. So the "textframe" thing sounds wrong to me. Means keyboard focus lands on an item that has neither the button role nor the aria-label. Finding that out, then bringing it all in sync should be the first step. And then, you can decide on what this should sound like actually. :)

	Marco Zehe (:MarcoZ)
	Comment 7 • 10 years ago

Hi Athena, are you still interested in working on this bug?

	Athena Assignee
	Comment 8 • 10 years ago

Hi Marco, sorry for the silence! Definitely still interested. I've not had a chance to work on this because of a lack of time and intermittent computer access -- both of which aren't an issue as of today.

Let me wrap up Bug 911148 first. The focus jumps around after exiting edit mode and that's made testing more difficult than it should be.