Problem/Motivation

This is a followup of #2113931: File Field design update: Upload field.. When trying to implement the created file field designs we found that it was really hard to make that design accessible. It was decided to start over since new designs were already being worked on for the Claro theme. Finding how hard it was to make something accessible afterwards, we want to now start with created accessible markup for the field, and design from there.

Proposed resolution

Let's explore and create some beautiful markup.

We should also ensure that there is an alternative that doesn't rely on pointer interaction:

f the drag and drop element is implemented, then making sure that it is accessible to non-sighted and keyboard-only users is a must-have, not a should-have. In this case, this can simply mean bypassing the drag and drop interaction points entirely and moving a keyboard only user to the clickable upload button.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Issue fork drupal-3064084

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

    Comments

    seanB created an issue. See original summary.

    wwalsh’s picture

    Am working on this today at #design4drupal contrib day.

    jacob@redfinsolutions.com’s picture

    In case it helps anyone or can work as a starting point here's the markup from the Drupal usability meeting on 06-25-19 (Demo starts here, about 38 minutes in: https://youtu.be/aipwkFhZDms?t=2265)

    <!DOCTYPE html>
    <html lang="en">
    <head>
        <meta charset="UTF-8">
        <title>Example</title>
    </head>
    <body cz-shortcut-listen="true">
        <h1>File Input with large dropzone demo</h1>
        <p>These two forms each has a single file input which has been visually hidden.Instead, they both have a visible fake-button. The big square containers might have some JS drag-and-drop functionality added later, but these are just plain file inputs for now.</p>
        <p>Form 1 uses a LABEL as the big square zone and a span as the visible fake-button. Clicking anywhere inside the big square should activate the hidden file input.</p>
        <form id="form-1" action=".">
            <label class="big-square">
                <input if="file-1" class="visuallyhidden" type="file" aria-label="Add file 2">
                <span class="fake-button">Add file</span>
            </label>
        </form>
        <p>Form 2 uses a DIV as the big square zone and a LABEL as the visible fake button. Clicking in the big square doesn't activate the file input, you need to click the fake button to do that.</p>
        <form id="form-2" action=".">
            <div class="big-square">
                <input id="file-2" class="visuallyhidden" type="file" aria-label="Add file 2">
                <label class="fake-button" for="file-2">Add file</label>
            </div>
        </form>
        <p>Some text after the form.</p>
    </body>
    </html>
    
    benjifisher’s picture

    Issue tags: +D4D19

    @jacob.morin:

    Thanks for transcribing that! The markup includes two variants of the upload form:

        <form id="form-1" action=".">
            <label class="big-square">
                <input if="file-1" class="visuallyhidden" type="file" aria-label="Add file 1">
                <span class="fake-button">Add file</span>
            </label>
        </form>
    

    and

        <form id="form-2" action=".">
            <div class="big-square">
                <input id="file-2" class="visuallyhidden" type="file" aria-label="Add file 2">
                <label class="fake-button" for="file-2">Add file</label>
            </div>
        </form>
    

    With suitable CSS, these look similar (as shown on the recording of the Usability meeting) even though the text "Add file" is in a <span> element in the first variant, in a <label> element in the second element.

    I think the idea is that either one enables drag-and-drop, just using browser support of the <input type="file"> form element, and also a button that can be clicked (for those who do not like drag-and-drop).

    There are some differences between the two variants when using assistive technology. For instance, when someone uses voice control with the command "Click button", the assistive tech will place markers next to each button, and the placement of those markers will be different in these two implementations.

    wwalsh’s picture

     <form id="uploadTest" enctype="multipart/form-data" role="form">
      <div class="upload-btn-wrapper">
      <p>Drag and drop multiple files onto the Choose Files button or click it to browse</p>
      <input type="file" name="fileUpload" aria-label="draganddrop" class="draganddrop" multiple>
       <button aria-label="upload"  id="upload" value="upload">Upload</button>
       </div>  
    </form>

    This works!!

    wwalsh’s picture

      <form id="uploadTest" enctype="multipart/form-data" role="form">
      <div class="upload-btn-wrapper">
      <p>Drag and drop multiple files onto the Choose Files button or click it to browse</p>
      <input type="file" name="fileUpload" aria-label="draganddrop" class="draganddrop" multiple onclick="google.script.run.logForm(document.getElementById('uploadTest'));">
       <button aria-label="upload"  id="upload" value="upload" >Upload</button>
       </div>  
    </form>

    OK, this one ACTUALLY WORKS. A little old school javascript onclick in there.

    mgifford’s picture

    Are there other examples that you could draw from? Not sure who else has tried to address this problem outside of Drupal.

    Sella Durai’s picture

    Status: Active » Needs work
    need to change a little design to looks good on ui part
    xjm’s picture

    Title: Create accessible markup for a drag & drop file upload widget » Create accessible markup for a drag & drop file upload widget (and ensure there is an accessible alternative interaction)
    Priority: Normal » Major
    Issue summary: View changes
    Status: Needs work » Active

    I wonder if the scope for this issue is too small? From #2834729-200: [META] Roadmap to stabilize Media Library:

    While this is a should have from an overall user expectation standpoint, from an accessibility standpoint, in my mind, it isn’t. However, if the drag and drop element is implemented, then making sure that it is accessible to non-sighted and keyboard-only users is a must-have, not a should-have. In this case, this can simply mean bypassing the drag and drop interaction points entirely and moving a keyboard only user to the clickable upload button.

    So we need not only accessible markup, but also an accessible alternative for the whole interaction that works with keyboard or voice navigation, or for non-sighted users. It sounds like allowing users to bypass drag-and-drop entirely is more important (and maybe preferable). That's the approach we took with the Layout Builder "move block" functionality as well.

    Expanding the IS and title to make sure we consider that as well.

    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.

    andypost’s picture

    Issue tags: +JavaScript

    It looks staled again

    ambient.impact’s picture

    Has it gone bad already? I swear we just put it in the fridge.

    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.

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

    Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

    Version: 9.4.x-dev » 9.5.x-dev

    Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

    Version: 9.5.x-dev » 10.1.x-dev

    Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

    Version: 10.1.x-dev » 11.x-dev

    Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

    shaal’s picture

    mgifford’s picture

    Thanks for adding that @shaal.

    I do think that there must be a reasonable solution to work for from that mix of links. Doesn't need to be perfect, but should be able to do up/down as well as left/right so that we can change order and hierarchy.

    Version: 11.x-dev » main

    Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

    Read more in the announcement.