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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Everett Zufelt’s picture

Title: Screen-reader users receive no info about file uploads » Screen-reader users receive no info about file upload status / success
mgifford’s picture

Issue tags: +D8UX usability

Or for that matter, that it failed. Pretty sure that this wouldn't be reported to AT either:

        var error = Drupal.t("The selected file %filename cannot be uploaded. Only files with the following extensions are allowed: %extensions.", {
          '%filename': this.value,
          '%extensions': extensionPattern.replace(/\|/g, ', ')
        });
        $(this).closest('div.form-managed-file').prepend('<div class="messages error file-upload-js-error">' + error + '</div>');

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.

Bojhan’s picture

Issue tags: -D8UX usability +Usability
mgifford’s picture

This 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.

mgifford’s picture

Issue tags: +file upload

Tagging.

mgifford’s picture

Issue tags: +aria

This is a good place to use WAI-ARIA to add the change of state.

mgifford’s picture

Status: Active » Needs review
FileSize
676 bytes

Not addressing the successful image upload, but the case of failure suggested in #2.

mgifford’s picture

#7: fileupload-1333292-7.patch queued for re-testing.

mgifford’s picture

tagging. This should be backported to D7. It's an admin thing, but also something that is part of many public user input forms.

Bojhan’s picture

Status: Needs review » Reviewed & tested by the community
webchick’s picture

Version: 8.x-dev » 7.x-dev
Status: Reviewed & tested by the community » Patch (to be ported)

Committed and pushed to 8.x. Thanks!

Moving down to 7.x.

dcam’s picture

Status: Patch (to be ported) » Needs review
FileSize
672 bytes

Backported #7 to D7.

mgifford’s picture

12: 1333292-12-file-upload.patch queued for re-testing.

mgifford’s picture

Well, 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?

mgifford’s picture

12: 1333292-12-file-upload.patch queued for re-testing.

mgifford’s picture

Issue summary: View changes
Status: Needs review » Reviewed & tested by the community
Issue tags: -

This still works as expected when I tested it manually today.

David_Rothstein’s picture

Version: 7.x-dev » 8.x-dev
Status: Reviewed & tested by the community » Active
Issue tags: +7.28 release notes

Committed 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?

  • Commit 808a61a on 7.x by David_Rothstein:
    Issue #1333292 by dcam, mgifford | Everett Zufelt: Screen-reader users...
mgifford’s picture

Agreed.. Would be good to have a positive confirmation as well. Thanks @David_Rothstein.

mgifford’s picture

andrewmacpherson’s picture

@mike the related issue looks like a mistake - this issue is referencing itself. Did you mean for some other issue to reference this one?

mgifford’s picture

Yup, 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!

mgifford’s picture

Title: Screen-reader users receive no info about file upload status / success » Screen-reader users receive information if file upload was successful

Changing the title to reflect the current problem.

mgifford’s picture

Version: 8.0.x-dev » 8.1.x-dev
Status: Active » Postponed

No work has been made to create a positive confirmation of file upload, so I am bumping this to 8.1 for now.

mgifford’s picture

Issue tags: +Drupal.announce

We should be using Drupal.announce() for announcing both the successful & failed uploads.

mgifford’s picture

Issue tags: +aria-live
mgifford’s picture

Status: Postponed » Needs review

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

mgifford’s picture

Status: Needs review » Needs work
Issue tags: +Needs reroll

Patch no longer applies.

  • webchick committed 0af77c2 on 8.3.x
    Issue #1333292 by mgifford: Fixed Screen-reader users receive no info...

  • webchick committed 0af77c2 on 8.3.x
    Issue #1333292 by mgifford: Fixed Screen-reader users receive no info...

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Manuel Garcia’s picture

Status: Needs work » Closed (outdated)
Issue tags: -Needs reroll

Afik this was fixed already, at least the aria-live="polite" is there.

mgifford’s picture

Status: Closed (outdated) » Needs work

I haven't tested this recently, but am pretty sure it is fixed if the file fails, but not if it is successful.

  • webchick committed 0af77c2 on 8.4.x
    Issue #1333292 by mgifford: Fixed Screen-reader users receive no info...

  • webchick committed 0af77c2 on 8.4.x
    Issue #1333292 by mgifford: Fixed Screen-reader users receive no info...

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

ok_lyndsey’s picture

Tested 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.
Screenshot file upload fail

On success; no message is read out if successful

On successful upload screen reader reads out [site name ] + link [file name] eg filename.doc

screenshot successful file upload

andrewmacpherson’s picture

I'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:

Screenshot of file upload error message.

The aria-live="polite" attribute introduced by patch #7 (committed already in D8) is in Drupal.file.validateExtension(), but I can't get this to appear in the DOM. I don't think this javascript is firing, because:

  • The screenshots in #38 say "The specified file ..." but the message in Drupal.file.validateExtension() is phrased "The selected file ...".
  • The message is wrapped with a <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:

  • I only see one copy of the message when testing with Chrome (v59 on Linux).
  • In a test with ChromeVox, it did start reading the second line of the message, but cut out before finishing. It said "The file is eleven-" but didn't go as far as finishing the sentence. I wonder if there's a timing issue here? Maybe some other event interrupting the screenreader, or a maximum time self-imposed by the screen reader. It consistently cut out at the same part of the message.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

quietone’s picture

Status: Needs work » Fixed
Issue tags: -JavaScript +JavaScript, +Bug Smash Initiative

This 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.

quietone’s picture

Version: 9.3.x-dev » 8.0.x-dev

Changing version to the version of the commit

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.