HPE SM Software for our disabled (half-blind) colleagues. Part 2
we need to make the HPE SM Software to do usable for our disabled (half-blind) colleagues.
There were several accessibility issues identified including various inconsistencies in UI element control or formatting/contrast settings in the accessibility audit report on Camelot.
Since the Camelot development team cannot solve them by customization, we urge you to fix the following issues or at least provide relevant alternate solutions:
1. If an error message affects several fields, these should be returned as a list.
2. Error messages should be consistent. The red error messages should be automatically keyboard - focused to allow quick closing by keyboard users. Optionally, closing by ESC key should be possible. Another viable option is to implement automatic closing after a preset time delay. This could also be implemented with green messages.
3. Error messages should be described in text in the title of the input window. Additionally, the Login-Formular for blind users should support the error message presentation with the role "alert".
4. Additionally, a distinct colour or text formatting should be used to mark a field with error.
5. With each interactive element, the blind users should be able to discern the typ (E.g. "checkbox"), the status (E.g. "ausgewählt/selected") and the purpose (E.g. the description of the checkbox and the corresponding form field group).
See Abbildung 3-8 , 3-9, 3-10 in the attached PDF
UI Element keyboard control should be consistent, e.g. Tab navigation:
1. The handling of UI elements should be consistent over the whole application. It is recommended to base the design of the keyboard controls to be compatible with other widely used UI's
2. Register tab groups should be reachable by using the tab key and further navigation using the left and right arrows should be possible. The next tab step should switch to the next interactive element.
Navigation within the notebook tabs should be consistent with navigation in the main menu tab:
1. Notebook tabs should be implemented in accordance with the main navigation tab and register tabs.
2. In order to achieve this, the links should be correspondingly marked as role "tablist" and "tab" and should be available for linear output as embedded lists.
3. In order to discern the start and end of the register tabs (also during TAB navigation), there should be a hint in the title attribute (or ARIA-attribute aria-describedby)of the first record in a list, describing the hierarchical level of the embedded list (e.g. Level 1 Table)
See Abbildung 3-13 in the attached PDF
Combofields should include hints( E.g. "combofield, please input text"):
1. Combofields should correctly output the role also in IE11 with JAWS15. This could be implemented e.g. by providing invisible text with role information "Kombiniertes Eingabefeld. Bitte geben Sie einen Text ein"
"Combofield, please type in the your input text"
Automatic Windows contrast settings for accessibility (visaully impaired users) are not observed.
1. It should guaranteed that the Windows contrast settings are applied to all content. All information for blind users should be legible even after the automatic contrast adjustment. Another option is to implement the contrast adjustment settings as additional functionality. In the latter case the application must be able to completely override the Windows system settings.
2. The contrast adjustment settings must be applied to all interactive elements. This is most critical for the following elements:
- arrow elements of foldable lists
3. It must be guaranteed that there will be no overlapping of the frame borders, foldable list text and buttons.
See Abbildung 3-18 in the attached PDF (some elements not distinguishable in high contrast mode)
SM should provide access keys for accessibility functions(that are not overriden by browser functions):
1. The configured application keyboard shortcuts must not be overridden by standard browser access keyboard shortcuts. E.g. access keys for menu expanding and collapsing.
See Abbildung 3-20 in the attached PDF (access keys of the application are overridden by browser shortcut keys)
Heading and list hierarchy must follow html standard (h1 to h6, ul > li):
1. The standard HTML heading elements <h1> to <h6> should be implemented in correct hierarchical order, i.e. the top level heading should be tagged as <h1>element, the next child level should be tagged as <h2> etc. This must be strictly observed especially in pages with paragraph headings, that are hidden from users with normal vision (class = "audible-text")
2. The redundant role "heading" should be removed.
3. All pop-up windows should be tagged by a 2nd level heading in order to improve the visibility of the new paragraph for users with impaired vision.
4. All lists should be tagged by <ul> and <li> tags
5. The usage of documented quick-navigation keys should be supported in all data tables.
See Abbildung 3-22 in the attached PDF (heading lists in the screenreader return different heading levels than in the linear reading mode)
Unnecessary tab steps should be avoided - fields that can not be edited should not be emphasized/focused, e.g.:
1. Inside a data table with file upload function, the focus should be put either on the cell or on the link.
2. Inside the pop-up "System Keyboard Shortcut List", each pair accesskey - description should be focused only once (e.g. by removing the tabindex attributes around the cells.
3. Empty input fields in framed blocks of input fields should not receive keyboard focus, if they do not contain any information, e.g. if they are deactivated. Alternatively, there can be dedicated access keys, which will allow to jump to the next non-empty field.
See Abbildung 3-24 in the attached PDF (the table quick navigation keys are not available)
See Abbildung 3-28 in the attached PDF (many unnecessary tab steps)
1. The tab focus should also be able to emphasize the <iframe> elements by using CSS properties. E.g. by using a blue frame as implemented with other elements
2. Embedded Iframes should be labeled with meaningfull <title> tag. Another option is to use a title or name attribute within the <frame> or <iframe> tag.
See Abbildung 3-30 in the attached PDF (the purpose of the frame is not identifiable)
The implementation of notebooks should observe the following recommendations:
1. The description of notebook register tabs should be presented only once by the screenreader. Additionally, the title attributes of notebooks that are implemented as links, should be removed. Additional information can be emphasized using the aria - label attribute instead.
2. The text "Notebook tab" should be presented at the end of the register card description.
3. Valid date format should be put out by the Screenreader for users with impaired vision. E.g. it can be embedded in the label.
when our disabled (half-blind) colleagues. are using HPE SM Software
our disabled (half-blind) colleagues can not use the software
Re: HPE SM Software for our disabled (half-blind) colleagues. Part 2
this one is tagged as AM but as i read it, appears to be SM. Also, it is somewhat concerning that this level of accessibility concern exists in SM where we have been working the issues for several releases now.
can you clarify please?
Betreff: HPE SM Software for our disabled (half-blind) colleagues. Part 2
Sorry, i didnt now what to choose, so I choosed randomly AM.
Our disabled colleagues checked the HPE SM Software and they send us the issues.