Add additional element types to the elements list in browse mode #588 #6131

LeonarddeR · 2016-07-02T13:38:03Z

From ticket #588:

If made in a future release, have controls on web pages be apart of the elements list, via the Alt-C command, listing all control items that are shown on a web page, which could also be filtered with the alt-f command.
For example, names of buttons, check boxes, edit boxes, combo boxes, etc. Then press enter or Alt-A to activate, focused control within element's list, or Alt-M to move to, focused control, while in element's list.

I agree with this proposal where it proposes adding additional elements to the elements list. This pull request does the following:

Add additional elements to the elements list, namely buttons, form fields, edit boxes, radio buttons, combo boxes, check boxes and graphics. Their shortcut keys correspond with the quicknav keys in browse mode
Rewrite virtualBuffers.VirtualBufferQuickNavItem.label to accomplish correct labelling of the different element types
Add REASON_ELEMENTSLIST to controlTypes in order to not show expanded and collapsed states in the elements list, as these states conflict with expanding/collapsing items in the the tree view. State filtering is done with controlTypes.getPositiveStates and controlTypes.getNegativeStates

Fixes #588

feerrenrut · 2016-12-09T02:42:42Z

With so many radio button options a dropdown menu would make more sense, since it is a lot more compact. However some logic will need to be added to ensure that the keyboard shortcuts still work.

jcsteh · 2016-12-09T03:20:31Z

@michaelDCurran, I think we discussed this a while ago, but clearly didn't document our conclusions. :( I'm not convinced we need to have all of these element types; the use case is sketchy at best. I can probably see the point in form fields, graphics and maybe buttons, but I don't see any use in listing separate form field types.

LeonarddeR · 2016-12-09T05:03:34Z

I implemented an alternative for this, didn't seod in a pr for that yet. It allows you to set a hotkey in browse mode to directly jump to a specific element in the list. For example, alt nvda h opens the elements list with headings selected.Ho about such a thing? N.B. Sent on behalf of @BabbageCom

…

Op 9 dec. 2016 om 03:42 heeft Reef Turner ***@***.***> het volgende geschreven: With so many radio button options a dropdown menu would make more sense, since it is a lot more compact. However some logic will need to be added to ensure that the keyboard shortcuts still work. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

LeonarddeR · 2016-12-09T06:13:45Z

@jcsteh: From a programmers perspective, I can understand perfectly why you think that listing separate form fields in here is slightly overkill. However, in my work as an AT trainer, I've met several people who used this element specific functionality, due to several reasons: * When you often navigate edit boxes with e or buttons with b, it is a little step to add modifiers like insert and alt to that hotkey in order to get a list of the element you're navigating. That's what I know many JAWS users do. Not that we blindly want to copy JAWS of course, but people who are accustomed to listing edit boxes might consider form field listing to give too much info. * Some people simply do not know that an edit field is a form field. I think they should know such things when they want to use a screen reader reliably, but it's a thing we might or might not keep in mind. But again, I can see why you think form fields is enough, and I will not oppose that. No problem to remove them from the pr. Just wanted to bring in some other arguments.

Brian1Gaff · 2016-12-11T10:57:29Z

What often might be very useful would be some way to know if a combo box was 'normal' ie you just use cursors to go around the selections, or one of those 'ever so unhelpful' ones where you need to hold another key down to stop it leaping off to somewhere if you pause for a moment while cursoring!Brian bglists@blueyonder.co.uk Sent via blueyonder. Please address personal email to:- briang1@blueyonder.co.uk, putting 'Brian Gaff' in the display name field. ----- Original Message ----- From: "James Teh" <notifications@github.com> To: "nvaccess/nvda" <nvda@noreply.github.com> Sent: Friday, December 09, 2016 3:20 AM Subject: Re: [nvaccess/nvda] Add additional element types to the elements list in browse mode #588 (#6131)

…

@michaelDCurran, I think we discussed this a while ago, but clearly didn't document our conclusions. :( I'm not convinced we need to have all of these element types; the use case is sketchy at best. I can probably see the point in form fields, graphics and maybe buttons, but I don't see any use in listing separate form field types. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: #6131 (comment)

derekriemer · 2016-12-11T20:51:00Z

As a rule of thumb, press alt+down to always do this, and when done, press enter. This is the correct way to use combo boxes, although some systems let you arrow around without this.

…

On 12/11/2016 3:57 AM, Brian1Gaff wrote: What often might be very useful would be some way to know if a combo box was 'normal' ie you just use cursors to go around the selections, or one of those 'ever so unhelpful' ones where you need to hold another key down to stop it leaping off to somewhere if you pause for a moment while cursoring!Brian ***@***.*** Sent via blueyonder. Please address personal email to:- ***@***.***, putting 'Brian Gaff' in the display name field. ----- Original Message ----- From: "James Teh" ***@***.***> To: "nvaccess/nvda" ***@***.***> Sent: Friday, December 09, 2016 3:20 AM Subject: Re: [nvaccess/nvda] Add additional element types to the elements list in browse mode #588 (#6131) > @michaelDCurran, I think we discussed this a while ago, but clearly didn't > document our conclusions. :( I'm not convinced we need to have all of > these element types; the use case is sketchy at best. I can probably see > the point in form fields, graphics and maybe buttons, but I don't see any > use in listing separate form field types. > > -- > You are receiving this because you are subscribed to this thread. > Reply to this email directly or view it on GitHub: > #6131 (comment) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#6131 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFGivc9EC4vjTxNzHFyRGIdEPemHY_SAks5rG9cagaJpZM4JDrTK>.

-- ------------------------------------------------------------------------ Derek Riemer * Department of computer science, third year undergraduate student. * Proud user of the NVDA screen reader. * Open source enthusiast. * Member of Bridge Cu * Avid skiier. Websites: Honors portfolio <http://derekriemer.com> Awesome little hand built weather app! <http://django.derekriemer.com/weather/> email me at derek.riemer@colorado.edu <mailto:derek.riemer@colorado.edu> Phone: (303) 906-2194

LeonarddeR · 2016-12-14T15:31:07Z

Have been thinking about this a little longer, and I wonder, is it clear for everyone that a button is a form field? Any how, if we remove buttons and only have form fields, it won't be possible to activate buttons from the elements list.

@feerrenrut: I assume four radio buttons isn't a problem from a visual perspective? Excel elements list has five of them.

jcsteh · 2016-12-15T06:15:11Z

I understand your arguments regarding check boxes, edit fields, etc. Nevertheless, I'd prefer to leave these out for now. We can always add them later if there's high demand, but it's much harder to remove them later. :) So, please go with form fields and buttons for now.

LeonarddeR · 2016-12-15T06:35:47Z

Sounds ok. How about graphics?

jcsteh · 2016-12-15T06:39:14Z

Is there a good use case for listing graphics? Why would one need to list graphics? I can understand wanting to find the next or previous one, but I'm not as clear as to why one would want to list them.

LeonarddeR · 2016-12-15T06:50:55Z

Honestly, I added them just to be complete, so I will remove them as well.

LeonarddeR · 2016-12-15T07:04:11Z

There you go, al additional form fields (except for buttons) and graphics have been removed.

feerrenrut · 2016-12-15T08:46:50Z

@LeonarddeR It's hard to say. It will really depend on the length of the text and the size of the dialog. There are different recommendations depending on where you look. The following two links from ux.stackexchange are interesting (radio-buttons-or-dropdown-for-same-list-of-options and dropdown-vs-radio-button). Things may need to be shuffled around so that the options can be laid out vertically. I can take a look at the PR and we can discuss it further if you like. Please mention me on it when you are ready.

LeonarddeR · 2016-12-15T10:44:42Z

@feerrenrut, thanks for your info. The current state of the request is actually ready for review. :)

feerrenrut

I've had a look at this. I think the number over radio buttons is ok. I would not want to add more though.

I terms of the implementation, I'm not very familiar with this area of code. It looks ok to me, but I'm unlikely to spot issues that may crop up in code that depends on the changed areas. Perhaps @jcsteh will have a quick look over it?

feerrenrut · 2017-01-09T04:17:28Z

source/virtualBuffers/__init__.py

@@ -109,14 +109,30 @@ def obj(self):

 	@property
 	def label(self):
-		if self.itemType == "landmark":


I would love to see some documentation added here. Specifically talking about what label is and how its expected to be used. I realise that you didn't introduce this, but since you are in the area and have taken the time to understand this code it would be beneficial if this was documented better.

The documentation for this property belongs in browseMode.TextInfoQuickNavItem.label, as that's where the base property is defined. Only because this touches a completely different file, I'd suggest we leave this for this PR.

jcsteh

Thanks! The essentials look great, though I do have some concerns regarding the states stuff.

jcsteh · 2017-01-10T04:58:14Z

source/virtualBuffers/__init__.py

+		value = super(VirtualBufferQuickNavItem,self).label
+		# Translators: Reported label in the elements list for an element which which has no name and value
+		unlabeled = _("Unlabeled")
+		if self.itemType is not "heading":


I think this would be easier to follow if you move the heading code first, since there's only a tiny bit of code for headings and a lot for other stuff. In fact, you can just return early for headings and then you can get rid of a whole extra level of indentation for the rest.

Good point there.

jcsteh · 2017-01-10T05:04:55Z

source/virtualBuffers/__init__.py

-				name += " "
-			return name + aria.landmarkRoles[attrs["landmark"]]
+			realStates=attrs["states"]
+			positiveStates = " ".join(controlTypes.stateLabels[st] for st in controlTypes.processPositiveStates(roleRaw, realStates, controlTypes.REASON_ELEMENTSLIST, realStates))


This states stuff seems a bit arbitrary at the moment.

Do we really need states at all here? Sure, I guess this means you get to hear "check box not checked" or the like, but I'm not convinced we need that in the Elements List anyway. If the user is using the list, they are trying to find a specific control. If they want an overview of the form's values, they should be using quick navigation, no?

I'm a bit bothered by introducing REASON_ELEMENTSLIST when it's really only used for states calculation. Furthermore, we just use it to kill the collapsed state... but why the collapsed state? If we really do want specific states, I feel we should perhaps be explicit about that. Otherwise, we could just be continually adding more and more exceptions in controlTypes.

Perhaps we can answer both of these questions if you can give me some specific use cases you had in mind here.

At the very least, we'd need some comments here explaining why these choices were made.

Do we really need states at all here? Sure, I guess this means you get to hear "check box not checked" or the like, but I'm not convinced we need that in the Elements List anyway. If the user is using the list, they are trying to find a specific control. If they want an overview of the form's values, they should be using quick navigation, no?

One reason to do it like this, is that the other screen readers with elements lists (SuperNova and JAWS) also show the element states. Note that one who uses the elements list doesn't necessarily use it to find a particular element, but can also use it to get an overview of elements as well as review input in a form. I agree that quick navigation has preference in most, but not all cases. Imagine the case where you have a form full of check boxes, including an "i agree" one. An elements list with states would allow a user to quickly jump to that particular control with first letter navigation, thereby hearing the current state.

I'm a bit bothered by introducing REASON_ELEMENTSLIST when it's really only used for states calculation. Furthermore, we just use it to kill the collapsed state... but why the collapsed state? If we really do want specific states, I feel we should perhaps be explicit about that. Otherwise, we could just be continually adding more and more exceptions in controlTypes.

I added this because reporting the collapsed state doesn't make any sense in the elements list, as a collapsible item like a combo box isn't usually expanded when you are in the elements list. It is one of the states you wouldn't bother about.

@jcsteh: Do the explanationss above sound sensible to you?
I've been thinking about it a bit more and I agree that REASON_ELEMENTSLIST should be avoided here. We can discard the collapsed state in the elements list code anyway, if we still want that.

…ed for form controls, such as edit and check boxes.

…iscussed in #6131

…ment lists label retrival

LeonarddeR · 2017-04-26T13:52:07Z

@jcsteh or @feerrenrut, this is ready for another review if you'd like.

jcsteh

Sorry it's taken me so long to get back to this.

Thanks for the explanation and use case regarding why you're including states. It makes sense. That said:

I would still prefer that we got rid of REASON_ELEMENTSLIST. As you noted, we can put code to discard specific states in QuickNavItem.label.
The decision as to what to include still seems a bit arbitrary to me. For example, we only include positive states for buttons, but both positive and negative for other form fields. Why? There might be a good reason, but if there is, it needs to be commented.
Speaking of commenting, it'd be good if you could include some comments with example output for each case you handle. That might make it easier to see what's going on here.

LeonarddeR · 2017-05-23T13:37:54Z

Sorry it's taken me so long to get back to this.

No problem

I would still prefer that we got rid of REASON_ELEMENTSLIST. As you noted, we can put code to discard specific states in QuickNavItem.label .

No problem. The question is though, what reason should I use instead? REASON_QUERY seems not ok, since that will keep states like STATE_READONLY for elements other than ROLE_EDITABLETEXT and ROLE_CHECKBOX. Or shouldn't we bother about that?

The decision as to what to include still seems a bit arbitrary to me. For example, we only include positive states for buttons, but both positive and negative for other form fields. Why? There might be a good reason, but if there is, it needs to be commented.

It has been too long ago I wrote this code. I see no valid reason for why I did this, so Negative states will now be reported for buttons as well. We do have toggle buttons where this is relevant.

Speaking of commenting, it'd be good if you could include some comments with example output for each case you handle. That might make it easier to see what's going on here.

I will do that as soon as the reason issue has been tackled.

LeonarddeR · 2017-05-23T13:46:52Z

Ah, REASON_QUERY also keeps STATE_LINKED, so we definitely need to discard some states. Alternatively, we can just pass None as the reason, but I do not prefer that...

LeonarddeR · 2017-05-23T14:45:42Z

Sorry for spamming so much. I got one additional alternative, REASON_QUICKNAV. Since the label property is part of a TextInfoQuickNavItem, this sounds quite reasonable.

LeonarddeR · 2017-06-29T05:58:14Z

This is perhaps a tiny bit ugly and assumes that ControlField key names are the same as NVDAObject attribute names, but that's definitely true for the attributes you need here.

I actually like this approach a lot. In the case of UIA, it will not work for landmark as that is no object property, but we can work around that of course. We can also consider setting a landmark property on the Edge UIA objects by default, which could be added to #7328. But, I'm reluctant to do such a thing.

accessaces · 2017-07-27T00:54:45Z

I'd like to see this fully implemented soon as it will really help in my work testing websites for developers. Being able to show them a list of all the elements or separate elements is key. I often have to switch to jaws to get screenshots of what graphic labels are or screenshots of different form controls. I would really like you to add the graphics and individual form controls.it would be key to accessibility testers like myself to be able to show these types of elements separately and together less often together. This would mean one last task I have to do in jaws when it comes to writing reports on improper labeled controls elements and so forth.

jcsteh · 2017-08-02T01:17:47Z

@accessaces commented on 27 Jul 2017, 10:54 GMT+10:

I would really like you to add the graphics and individual form controls.it would be key to accessibility testers like myself to be able to show these types of elements separately and together less often together.

While accessibility testing is a use case we obviously want to support as much as we can, we can't do that at the expense of normal usage. Adding all of these options clutters the UI significantly, and as I explained in previous comments, there's no real world use case for this (in normal usage). If we did want to support all of these elements for accessibility testing, perhaps this could be done in an add-on somehow.

jcsteh · 2017-08-02T01:18:20Z

@LeonarddeR, status update? Were you going to make changes based on #6131 (comment)?

LeonarddeR · 2017-08-02T16:50:44Z

I've actually been waiting for #7328 to be merged in Master, which it is now. I can start working on this again in the near future.

@jcsteh commented on 2 aug. 2017 03:18 CEST:

Were you going to make changes based on #6131 (comment)?

Yes.

LeonarddeR · 2017-08-12T12:58:35Z

@jcsteh: this is ready for another round of review.

jcsteh · 2017-08-16T00:51:55Z

source/browseMode.py

@@ -196,6 +196,44 @@ def isAfterSelection(self):
 		caret=self.document.makeTextInfo(textInfos.POSITION_CARET)
 		return self.textInfo.compareEndPoints(caret, "startToStart") > 0

+	def _getLabelForProperties(self, labelPropertyGetter):
+		"""
+		Fetches required properties for this L{TextInfoQuickNavItem} and constructs a label to be shown in an elements list.


Please add a line after this which is something like the following:

This can be used by subclasses to implement the L{label} property.

jcsteh · 2017-08-16T00:52:53Z

source/browseMode.py

+	def _getLabelForProperties(self, labelPropertyGetter):
+		"""
+		Fetches required properties for this L{TextInfoQuickNavItem} and constructs a label to be shown in an elements list.
+		@Param labelPropertyGetter: A callable taking 1 argument.


Please clarify what the argument is; e.g. "taking one argument specifying the property to fetch".

jcsteh · 2017-08-16T00:54:27Z

source/browseMode.py

+		"""
+		Fetches required properties for this L{TextInfoQuickNavItem} and constructs a label to be shown in an elements list.
+		@Param labelPropertyGetter: A callable taking 1 argument.
+			For example, if L{itemType} is landmark, the callable must return the landmark type when the landmark argument is provided to it.


'when the landmark argument is provided to it': This would be clearer as something like 'when "landmark" is passed as the property argument'

jcsteh · 2017-08-16T00:55:30Z

source/browseMode.py

+		Fetches required properties for this L{TextInfoQuickNavItem} and constructs a label to be shown in an elements list.
+		@Param labelPropertyGetter: A callable taking 1 argument.
+			For example, if L{itemType} is landmark, the callable must return the landmark type when the landmark argument is provided to it.
+			Alternative attributes or dictionary keys might be name or value.


Perhaps 'Alternative property names might be "name" or "value"'? I understand why you're talking about attributes/keys here, but I'm finding this confusing to read given that this thing talks about property getting.

jcsteh · 2017-08-16T00:56:19Z

source/browseMode.py

+			For example, if L{itemType} is landmark, the callable must return the landmark type when the landmark argument is provided to it.
+			Alternative attributes or dictionary keys might be name or value.
+			An expected callable might be the __getattribute__ method on an L{NVDAObject}, or the get method on a L{Dict}.
+			Note that L{Dict.get} doesn't raise an exception, it returns None instead.


Rather than talking about dict.get here, it's probably best to say that the callable must return None if the property doesn't exist rather than raising an exception.

Is there such a callable for objects, instead of getattribute? For objects, we're never fetching attributes that an object does not have, so in theory, getattribute is ok.

I'd just use: lambda prop: getattr(obj, prop, None).

jcsteh · 2017-08-16T00:58:15Z

source/browseMode.py

+			An expected callable might be the __getattribute__ method on an L{NVDAObject}, or the get method on a L{Dict}.
+			Note that L{Dict.get} doesn't raise an exception, it returns None instead.
+		"""
+		value = self.textInfo.text.strip()


It might be better to name this variable text or content rather than value, as value is confusing with respect to buttons, etc.

jcsteh · 2017-08-16T01:00:00Z

source/browseMode.py

+			negativeStates = " ".join(controlTypes.negativeStateLabels[st] for st in controlTypes.processNegativeStates(role, realStates, controlTypes.REASON_FOCUS, realStates))
+			if self.itemType is "formField":
+				if role in (controlTypes.ROLE_BUTTON,controlTypes.ROLE_DROPDOWNBUTTON,controlTypes.ROLE_TOGGLEBUTTON,controlTypes.ROLE_SPLITBUTTON,controlTypes.ROLE_MENUBUTTON,controlTypes.ROLE_DROPDOWNBUTTONGRID,controlTypes.ROLE_SPINBUTTON,controlTypes.ROLE_TREEVIEWBUTTON):
+					labelParts = (value or name or unlabeled, roleText, positiveStates, negativeStates)


It'd be good to have a comment with example content that might be produced by each of these conditions:

# For example: "Mute toggle button pressed"

jcsteh · 2017-08-16T01:03:54Z

source/virtualBuffers/__init__.py

-			return name + aria.landmarkRoles[attrs["landmark"]]
-		else:
-			return super(VirtualBufferQuickNavItem,self).label
+		value = super(VirtualBufferQuickNavItem,self).label


This always gets executed, but it's only used for "heading". But we also fetch the text of the TextInfo in _getLabelForProperties, which results in a wasted call (this property isn't cached). So, I think this call to super should be moved inside the if block.

jcsteh · 2017-08-16T01:04:42Z

source/virtualBuffers/__init__.py

-			return super(VirtualBufferQuickNavItem,self).label
+		value = super(VirtualBufferQuickNavItem,self).label
+		if self.itemType is "heading":
+			# Explicitly handle headings here as well, to avoid requesting the Control field attribs


This comment says "as well". As well as what? Unless I'm missing something, "as well" should be removed.

jcsteh · 2017-08-16T01:12:11Z

source/virtualBuffers/__init__.py

-			return super(VirtualBufferQuickNavItem,self).label
+		value = super(VirtualBufferQuickNavItem,self).label
+		if self.itemType is "heading":
+			# Explicitly handle headings here as well, to avoid requesting the Control field attribs


Another way of doing this so you can rely entirely on _getLabelForProperties would be to make a lazy fetcher for control field attributes. This might be overkill, but I'll let you decide. It would go something like this:

attrs = {} def propertyGetter(prop): if not attrs: # Lazily fetch the attributes the first time they're needed. # We do this because we don't want to do this if they're not needed at all. attrs.update(self.textInfo._getControlFieldAttribs(self.vbufFieldIdentifier[0], self.vbufFieldIdentifier[1])) return attrs.get(prop)

LeonarddeR · 2017-08-16T07:26:38Z

@jcsteh: I addressed your comments. Furthermore, I decided that it would be more readable for users to have a semicolon between the label parts ("mute; toggle button; pressed" instead of "mute toggle button pressed"). Especially when there is no role, such as for links and buttons, having the state directly behind the name or content can be misinterpreted.

…bels

jcsteh

Fantastic, except for one tiny tiny nit.

jcsteh · 2017-08-17T00:15:36Z

source/browseMode.py

+		"""
+		Fetches required properties for this L{TextInfoQuickNavItem} and constructs a label to be shown in an elements list.
+		This can be used by subclasses to implement the L{label} property.
+		@Param labelPropertyGetter: A callable taking 1 argument, specifying the property to fetch".


Spurious '"' character before full stop. :)

…ubates #6131. Issue #588.

jcsteh

Oops, I did review this before incubating; just forgot to hit approve. :)

…ield (nvaccess#12317) Fix-up of PR nvaccess#6131

feerrenrut mentioned this pull request Dec 15, 2016

Allow moving to form fields in MS word. #6643

Open

feerrenrut reviewed Jan 9, 2017

View reviewed changes

jcsteh requested changes Jan 10, 2017

View reviewed changes

Leonard de Ruijter added 6 commits January 10, 2017 18:18

Added buttons to the list of elements in browse mode (#588)

4370731

Added several new element types to the elements list (#588)

851df5c

In the Elements list, meaningful label information can now be display…

028ac25

…ed for form controls, such as edit and check boxes.

Removed graphics and separate form fields from the elements list as d…

285e26d

…iscussed in #6131

Changed documentation for #588

96a144c

As requested in #6131, we now return much earlier for headings in ele…

9fffcd6

…ment lists label retrival

jcsteh requested changes May 16, 2017

View reviewed changes

Merge branch 'master' into i588

3902248

Review changes for #588

5109da5

LeonarddeR mentioned this pull request Jun 29, 2017

Direct Jump To Specific Element, Inside Elements List Dialog, and Elements List Enhanscement #588

Closed

LeonarddeR mentioned this pull request Jul 6, 2017

Fixed Edge landmark detection to work for Windows languages other than English #7333

Merged

Leonard de Ruijter added 2 commits August 12, 2017 14:52

Review actions

255a2e5

Merge branch 'master' into i588, fixing merge conflicts

70e8d9d

jcsteh mentioned this pull request Aug 14, 2017

Elements list dialog box improvements #4279

Closed

jcsteh requested changes Aug 16, 2017

View reviewed changes

Review actions. Also inserted ; as separator for label parts

a59af98

Use lambda prop: getattr(self.obj, prop, None) for UIA browse mode la…

865607e

…bels

jcsteh requested changes Aug 17, 2017

View reviewed changes

Final review action, for now

5b8c26d

jcsteh added a commit that referenced this pull request Aug 17, 2017

Add additional element types to the elements list in browse mode. Inc…

2c247f2

…ubates #6131. Issue #588.

nvaccessAuto added the incubating label Aug 17, 2017

nvaccessAuto assigned jcsteh Aug 17, 2017

jcsteh approved these changes Aug 22, 2017

View reviewed changes

jcsteh merged commit d869253 into nvaccess:master Aug 31, 2017

nvaccessAuto removed the incubating label Aug 31, 2017

nvaccessAuto added this to the 2017.4 milestone Aug 31, 2017

LeonarddeR mentioned this pull request Dec 13, 2017

Filtering or loading the elements lists sometimes results in one or more LookupError entries in the log #7853

Open

LeonarddeR added the BabbageWork Pull requests filed on behalf of Babbage B.V. label Oct 11, 2019

JulienCochuyt mentioned this pull request Apr 21, 2021

[html5 input type="number"] Label missing from the Elements List when the field is not empty #12317

Closed

JulienCochuyt added a commit to accessolutions/nvda that referenced this pull request Apr 21, 2021

Elements List: Don't remove the label of a filled spin button input f…

aec2428

…ield (nvaccess#12317) Fix-up of PR nvaccess#6131

JulienCochuyt mentioned this pull request Apr 21, 2021

Elements List: Don't remove the label of a filled spin button input field (#12317) #12318

Merged

7 tasks

xi mentioned this pull request Jun 20, 2024

Idea: navigate through <form> elements xi/a11y-outline#12

Closed

Add additional element types to the elements list in browse mode #588 #6131

Add additional element types to the elements list in browse mode #588 #6131

Conversation

LeonarddeR commented Jul 2, 2016 • edited Loading

feerrenrut commented Dec 9, 2016

jcsteh commented Dec 9, 2016

LeonarddeR commented Dec 9, 2016 via email

LeonarddeR commented Dec 9, 2016 via email

Brian1Gaff commented Dec 11, 2016 via email

derekriemer commented Dec 11, 2016 via email

LeonarddeR commented Dec 14, 2016

jcsteh commented Dec 15, 2016

LeonarddeR commented Dec 15, 2016 via email

jcsteh commented Dec 15, 2016 via email

LeonarddeR commented Dec 15, 2016 via email

LeonarddeR commented Dec 15, 2016 via email

feerrenrut commented Dec 15, 2016

LeonarddeR commented Dec 15, 2016

feerrenrut left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jcsteh 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

LeonarddeR Jan 10, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

LeonarddeR commented Apr 26, 2017

jcsteh left a comment

Choose a reason for hiding this comment

LeonarddeR commented May 23, 2017

LeonarddeR commented May 23, 2017

LeonarddeR commented May 23, 2017

LeonarddeR commented Jun 29, 2017 • edited Loading

accessaces commented Jul 27, 2017

jcsteh commented Aug 2, 2017

jcsteh commented Aug 2, 2017

LeonarddeR commented Aug 2, 2017 • edited Loading

LeonarddeR commented Aug 12, 2017

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

LeonarddeR commented Aug 16, 2017

jcsteh left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jcsteh left a comment

Choose a reason for hiding this comment

LeonarddeR commented Jul 2, 2016 •

edited

Loading

LeonarddeR Jan 10, 2017 •

edited

Loading

LeonarddeR commented Jun 29, 2017 •

edited

Loading

LeonarddeR commented Aug 2, 2017 •

edited

Loading