Issue: the error icon, the close button and the file icon use fontawesome and fall for many of its issues.
1.3.1 Info and Relationships
Issue: the "Upload as a button" puts an <input> inside a <button>. All semantics of the input are lost this way and the role of the element is lost for AT users.
Fix: make sure the focused element has the right role.
Issue: the optional description message is visually close to the input but is not connected in code.
Fix: use aria-describedby to make sure AT can also notice the description message
Issue: errors are visually unclear (because of use of colour) and even less clear in code.
Fix: use the word error in a message and put aria-invalid on the input.
Recommendations
"Upload as a button" has a span to label the button. The use of aria-labelledby is unnecessary as the content of a button forms the accessible name of the button.
Clicking the label doesn't put the focus on the upload but triggers the actual upload. This is unusual behaviour.
The file list/queue is unclear both visually and in code. Suggestion to mark it up as a list of files with <ul> and <li>, and to add a heading to indicate the purpose of the list.
The "Custom upload" features two buttons that have no clear visual separation. It is also unclear what the difference in functionality is , from the text on the buttons. The upload field also states "click to upload" which seems to overlap with the button labelled "upload".
The optional description message is after a rather large input field. It is easy to miss for users who are zoomed in. It would get more attention (at the right moment) between label and input.
An upload can fail due to a wrong mime type and there seems to be a maximum file size as well. These kind of criteria sound more like instructions than errors and could be placed inside the description message.
A message in all caps like "INVALID_MIME_TYPE" is read by AT like an abbreviation and is not human readable. Consider writing actual error messages.
The use of a close button with a file or error message is unclear as it is not unique or visually labelled.
MichaelCastiau
commented
3 years ago
Erik and Roel reported back these issues.
1.1.1 Non-text Content
1.3.1 Info and Relationships
<input>inside a<button>. All semantics of the input are lost this way and the role of the element is lost for AT users. Fix: make sure the focused element has the right role.aria-describedbyto make sure AT can also notice the description messagearia-invalidon the input.Recommendations
"Upload as a button" has a
spanto label thebutton. The use ofaria-labelledbyis unnecessary as the content of abuttonforms the accessible name of thebutton.Clicking the
labeldoesn't put the focus on the upload but triggers the actual upload. This is unusual behaviour.The file list/queue is unclear both visually and in code. Suggestion to mark it up as a list of files with
<ul>and<li>, and to add a heading to indicate the purpose of the list.The "Custom upload" features two buttons that have no clear visual separation. It is also unclear what the difference in functionality is , from the text on the buttons. The upload field also states "click to upload" which seems to overlap with the button labelled "upload".
The optional description message is after a rather large input field. It is easy to miss for users who are zoomed in. It would get more attention (at the right moment) between label and input.
An upload can fail due to a wrong mime type and there seems to be a maximum file size as well. These kind of criteria sound more like instructions than errors and could be placed inside the description message.
A message in all caps like "INVALID_MIME_TYPE" is read by AT like an abbreviation and is not human readable. Consider writing actual error messages.
The use of a close button with a file or error message is unclear as it is not unique or visually labelled.