This is remarkably simple. No labeling should need to be done for buttons, check boxes, tabs, menu bars, menu items, menus, labels, and so forth. Labeling is required for edit boxes, tree views, combo boxes, spin boxes, dials, sliders, calendars, colormaps, column views, date/date time edits, double spin boxes, etc. To label items that need to be labeled, set its accessible name. Optionally, set its accessible description. The accessible description should be something that can fit within one-three lines, maximum, and no longer; keep in mind that the screen reader (if it understands accessible description indicators) will read this when moving over the control. You should not have to set the accessible role.
In summary, here are the "accessibility-related" things that you can set/get:
Accessible name: a screen-reader-friendly name that identifies the control. Will not be visible on the screen. (I usually set this to the label of the control.)
Accessible description: a short summary that will identify what the control does, or will identify what the control must contain, etc. Optional. Some screen readers (NVDA mainly) do not recognize this from GUI toolkits like QT, but do recognise it from other ones. Keep this in mind.
Accessible role: the role (the "type"/"class") of the control. Determines how the control will be viewed and interacted with by the screen reader and, by extension, by the user. Do not touch unless necessary. Some GUI toolkits (QT in particular) do not allow you to alter this particular attribute. Others (Windows Forms in particular) do allow you to do this. Again, do not touch this; it is very easy to confuse a user into believing that something is an edit box when it is actually a tree view, and can cause strange behavior when the screen reader attempts to send a message to the control that the control will most likely ignore, and can cause user confusion.
Additionally, you can also set what is known as the 'focus policy'. The focus policy determines how the control behaves when it takes keyboard focus. Labels, for example, will pass the focus to the next control in the focus chain by default. (So far as I know, QT is the only GUI toolkit that allows you to change this.) In QT at least, there are five focus policies:
Tab focus: the widget accepts focus by tabbing. (This is the default for most controls.)
Click focus: the widget accepts focus by clicking. (Default for controls like labels, graphics, etc.)
Strong focus: the widget accepts focus by both tabbing and clicking. On macOS this will also indicate that the widget accepts tab focus when in 'Text/List focus mode'.
Wheel focus: akin to strong focus with the addition of allowing focus with the mouse wheel.
No focus: the widget does not accept focus.
"On two occasions I have been asked [by members of Parliament!]: 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out ?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question." — Charles Babbage.
My Github