After running across #1332694: Disable AHAH (javascript) on filefield I realized that I should open an issue.
Currently there is little information / context to help a screen-reader user understand what is happening when they upload a file using a file field. This is true for both those w/ Javascript disabled and enabled.
I don't really think that there is much to do for those w/ JS disabled, and there is at least the knowledge that the page has reloaded.
For those w/ JS enabled we should be adding a WAI-ARIA live region to indicate that the file is being uploaded / upload has completed.
Comment | File | Size | Author |
---|---|---|---|
#39 | 1333292-39-screenshot-single-file-error-message.png | 106.99 KB | andrewmacpherson |
#38 | Create Article _file_successful_screen_reader.png | 9.16 KB | ok_lyndsey |
#38 | Create Article _file error_field_screen_reader.png | 13.3 KB | ok_lyndsey |
#12 | 1333292-12-file-upload.patch | 672 bytes | dcam |
#7 | fileupload-1333292-7.patch | 676 bytes | mgifford |
Comments
Comment #1
Everett Zufelt CreditAttribution: Everett Zufelt commentedComment #2
mgiffordOr for that matter, that it failed. Pretty sure that this wouldn't be reported to AT either:
I took a quick look and couldn't find a "Success" announcement. Believe it just stops loading and appears. Maybe a happy message would be useful to display for everyone for when there is a success.
Comment #3
Bojhan CreditAttribution: Bojhan commentedComment #4
mgiffordThis is related to #1272990: Make tabledrag warning message show when row weights are enabled, and add WAI-ARIA live region - a generalized solution would be very useful here.
Comment #5
mgiffordTagging.
Comment #6
mgiffordThis is a good place to use WAI-ARIA to add the change of state.
Comment #7
mgiffordNot addressing the successful image upload, but the case of failure suggested in #2.
Comment #8
mgifford#7: fileupload-1333292-7.patch queued for re-testing.
Comment #9
mgiffordtagging. This should be backported to D7. It's an admin thing, but also something that is part of many public user input forms.
Comment #10
Bojhan CreditAttribution: Bojhan commentedComment #11
webchickCommitted and pushed to 8.x. Thanks!
Moving down to 7.x.
Comment #12
dcam CreditAttribution: dcam commentedBackported #7 to D7.
Comment #13
mgifford12: 1333292-12-file-upload.patch queued for re-testing.
Comment #14
mgiffordWell, I can't seem to see either the file-upload-js-error class or aria-live="polite" when I upload a file here node/add/article
I'm missing something.... But ya, it shouldn't take a year to backport an issue to D7.
EDIT: Any illegal file type should be sufficient to tell you that it failed, right?
Comment #15
mgifford12: 1333292-12-file-upload.patch queued for re-testing.
Comment #16
mgiffordThis still works as expected when I tested it manually today.
Comment #17
David_Rothstein CreditAttribution: David_Rothstein commentedCommitted to 7.x - thanks!
Sounds like this should go back to Drupal 8 though, since the original issue was about what happens when the file upload is a success?
Comment #19
mgiffordAgreed.. Would be good to have a positive confirmation as well. Thanks @David_Rothstein.
Comment #20
mgiffordadding related issue.
Comment #21
andrewmacpherson CreditAttribution: andrewmacpherson commented@mike the related issue looks like a mistake - this issue is referencing itself. Did you mean for some other issue to reference this one?
Comment #22
mgiffordYup, seemed to have made a mistake there. I've done that before too...
This is better, but think I'd stumbled across another one.
Thanks for pointing it out!
Comment #23
mgiffordChanging the title to reflect the current problem.
Comment #24
mgiffordNo work has been made to create a positive confirmation of file upload, so I am bumping this to 8.1 for now.
Comment #25
mgiffordWe should be using Drupal.announce() for announcing both the successful & failed uploads.
Comment #26
mgiffordComment #27
mgiffordComment #29
mgiffordPatch no longer applies.
Comment #33
Manuel Garcia CreditAttribution: Manuel Garcia as a volunteer and at Appnovation commentedAfik this was fixed already, at least the
aria-live="polite"
is there.Comment #34
mgiffordI haven't tested this recently, but am pretty sure it is fixed if the file fails, but not if it is successful.
Comment #38
ok_lyndsey CreditAttribution: ok_lyndsey as a volunteer commentedTested using NDVA; Chrome on Windows in D 8.4.x
Tested failed file upload; NDVA screen reader reads:
Alert specified file could not be uploaded
Create [website name] document
Second line of error message is not read out
Duplicate error message displays on page.
On success; no message is read out if successful
On successful upload screen reader reads out [site name ] + link [file name] eg filename.doc
Comment #39
andrewmacpherson CreditAttribution: andrewmacpherson as a volunteer and at Annertech commentedI've lost track of where this issue is at, or what we're still trying to fix.
I ran a quick manual test with the user picture field, trying to upload a file which was too big:
The
aria-live="polite"
attribute introduced by patch #7 (committed already in D8) is inDrupal.file.validateExtension()
, but I can't get this to appear in the DOM. I don't think this javascript is firing, because:Drupal.file.validateExtension()
is phrased "The selected file ...".<div role="alert">
, not a<div aria-live="polite">
I think this is probably a generic form error message being returned by the AJAX system.
Some other things I noticed:
Comment #48
quietone CreditAttribution: quietone as a volunteer commentedThis was committed to 8.x in Jan 2013. It was re-opened in #14 because the patch failed manual testing for the case of a successful file upload. This was committed to 7.28 in May 2014. I don't see any testing to confirm if that work for the case of a successful file upload. This issue bounced a bit between Drupal 7 and Drupal 8 and despite the commits this was never marked fixed.
As it stands this issue is about ensuring that screen-reader users receive information that a file upload was successful. I know that is the intent of the title but it hasn't turned out that way. Since this was never reverted and it has been 4 years since the last testing I think the best way to make progress is to close this and open a new issue. Experience in bug smash initiative is that issues like this that get re-opened tend to become difficult to follow and don't get a lot of attention and then there can also be confusion if there are two commits referencing the same issue number.
Made a new issue #3244803: Ensure that screen-reader users receive information that a file upload succeededul and moved credit. Further work should happen there.
Closing this a fixed.
Comment #49
quietone CreditAttribution: quietone as a volunteer commentedChanging version to the version of the commit