The edit of a contact has for email, websites and phone numbers multiple entries.
For the email Henry and me agreed upon a table layout for the type of the email, the value and the default email. This associates multiple form controls to a single entry.

For websites and phone numbers this applies as well. They are currently grouped by a fieldset instead of a table. The task of this bug is to convert them to a table layout.

See the last two points at 1717632#c5

For the table layout see 1762126#c40

This work is currently blocked by the slot element within the edit. See Bug 1773031.

HI Henry,
I'd say that the table layout should also apply to the fields of Special Dates, consisting of a type of either Birthday or anniversary and Addresses which consists of several parts of an address like street, etc.
Would you agree?

(In reply to Nicolai Kasper from comment #1)

HI Henry,
I'd say that the table layout should also apply to the fields of Special Dates, consisting of a type of either Birthday or anniversary and Addresses which consists of several parts of an address like street, etc.
Would you agree?

Hmm. I've been thinking about this area and I'm doubting my original html:table suggestion. I've been discussing with @aleca about approaches, but there is no clear semantic structure that works well with a screen reader. At least testing with Orca, nothing works that well.

@aleca Can you copy and paste the examples into a testing page (like about:blank) and see how they read with JAWS and see which has the better user experience?

I'll look into whether Orca has some extra settings I can exploit to get better results.

Using a table

With column headers.

<form aria-label="test form">
  <fieldset>
    <legend>Name</legend>
    <label>
      First name
      <input>
    </label>
  </fieldset>
  <fieldset>
    <legend>Emails</legend>
    <table>
      <thead>
      <tr>
        <th scope="col" id="addressHeading">Email address</th>
        <th scope="col" id="defaultHeading">Default</th>
      </tr>
      </thead>
      <tbody>
      <tr>
        <td>
          <input aria-labelledby="addressHeading" />
        </td>
        <td>
          <input type="checkbox" aria-labelledby="defaultHeading" />
        </td>
      </tr>
      <tr>
        <td>
          <input aria-labelledby="addressHeading" />
        </td>
        <td>
          <input type="checkbox" aria-labelledby="defaultHeading" />
        </td>
      </tr>
    </tbody>
    </table>
    <button>Add email</button>
  </fieldset>
</form>

The problem is that Orca announces entering and leaving the table, but doesn't announce when switching rows when tabbing. So the row grouping is functionally lost.

With column and row headers

<form aria-label="test form">
  <fieldset>
    <legend>Name</legend>
    <label>
      First name
      <input>
    </label>
  </fieldset>
  <fieldset>
    <legend>Emails</legend>
    <table>
      <thead>
      <tr>
        <th></th>
        <th scope="col" id="addressHeading">Address</th>
        <th scope="col" id="defaultHeading">Default</th>
      </tr>
      </thead>
      <tbody>
      <tr>
        <th scope="row" id="row1">Email 1</th>
        <td>
          <input aria-labelledby="row1 addressHeading" />
        </td>
        <td>
          <input type="checkbox" aria-labelledby="row1 defaultHeading" />
        </td>
      </tr>
      <tr>
        <th scope="row" id="row2">Email 2</th>
        <td>
          <input aria-labelledby="row2 addressHeading" />
        </td>
        <td>
          <input type="checkbox" aria-labelledby="row2 defaultHeading" />
        </td>
      </tr>
    </tbody>
    </table>
    <button>Add email</button>
  </fieldset>
</form>

This makes it clearer when switching rows, but we have to generate the "Email <n>" row labels. And the "table" semantics doesn't play a role when tabbing through.

Using a list

<form aria-label="test form">
  <fieldset>
    <legend>Name</legend>
    <label>
      First name
      <input>
    </label>
  </fieldset>
  <fieldset>
    <legend>Emails</legend>
    <ul>
      <li>
        <label>
          Address
          <input />
        </label>
        <label>
          Default
          <input />
        </label>
      </li>
      <li>
        <label>
          Address
          <input />
        </label>
        <label>
          Default
          <input />
        </label>
      </li>
    </ul>
    <button>Add email</button>
  </fieldset>
</form>

Similar to the table, entering the list will be announced, but changing list items will not be announced.

Using sub-fieldsets

<form aria-label="test form">
  <fieldset>
    <legend>Name</legend>
    <label>
      First name
      <input>
    </label>
  </fieldset>
  <fieldset>
    <legend>Emails</legend>
    <fieldset>
      <legend>Email 1</legend>
      <label>
        Address
        <input />
      </label>
      <label>
        Default
        <input />
      </label>
    </fieldset>
    <fieldset>
      <legend>Email 2</legend>
      <label>
        Address
        <input />
      </label>
      <label>
        Default
        <input />
      </label>
    </fieldset>
    <button>Add email</button>
  </fieldset>
</form>

This is very explicit about changing rows, but it is noisy because it announces leaving and entering every fieldset.

Using counting labels.

Similar to the "row and column headers" table above, but we don't actually wrap any semantic structure around it

<form aria-label="test form">
  <fieldset>
    <legend>Name</legend>
    <label>
      First name
      <input>
    </label>
  </fieldset>
  <fieldset>
    <legend>Emails</legend>
    <div hidden="">
        <span id="addressHeading">Address</span>
        <span id="defaultHeading">Default</span>
        <span id="row1">Email 1</span>
        <span id="row2">Email 2</span>
    </div>
    <div>
        <input aria-labelledby="row1 addressHeading" />
        <input type="checkbox" aria-labelledby="row1 defaultHeading" />
    </div>
    <div>
        <input aria-labelledby="row2 addressHeading" />
        <input type="checkbox" aria-labelledby="row2 defaultHeading" />
    </div>
    <button>Add email</button>
  </fieldset>
</form>

This isn't that noisy. We lack an association between that links the rows together, but that wasn't really exposed by the above approaches either.

With column and row headers
Using counting labels.

These 2 examples were the only one in which JAWS was able to give a somewhat understandable separation of the inputs and checkboxes.
The table structure was the most clear, especially with both column and row headers, even tho it was a bit verbose.

The list example doesn't really work as there wasn't any readable context of the repeated nature of those fields.

So, my recommendation is to go with either of these 2:

• Table with column headers (we can also add row headers if we don't mind the verbosity when reading each field).
• Fieldsets with counting labels.

I wouldn't use subfieldset because it's indeed the noisier.

(In reply to Henry Wilkes [:henry] from comment #2)

(In reply to Nicolai Kasper from comment #1)

HI Henry,
I'd say that the table layout should also apply to the fields of Special Dates, consisting of a type of either Birthday or anniversary and Addresses which consists of several parts of an address like street, etc.
Would you agree?

Hmm. I've been thinking about this area and I'm doubting my original html:table suggestion. I've been discussing with @aleca about approaches, but there is no clear semantic structure that works well with a screen reader. At least testing with Orca, nothing works that well.
[...]

Hey,
are we okay with your html:table suggestion with 1774174#c3 from aleca?

So far I'd take the table with column headers like the email fields are now. (But without shadow dom).
But I'd like to know your opinion on that.
What do you think?

(In reply to Nicolai Kasper from comment #4)

Hey,
are we okay with your html:table suggestion with 1774174#c3 from aleca?

So far I'd take the table with column headers like the email fields are now. (But without shadow dom).
But I'd like to know your opinion on that.
What do you think?

The best approach (with "row" headings) would require new fluent strings, so won't work for 102.

I think we could attempt to use a <table> without row headings, but I'm not that confident it will have better results than it is now. I need a bit more time to think it over and maybe do some more research, so I'll keep my needinfo flag on here as a reminder.

Re 102, at this point we should be looking ahead and not limit the solution to what is back-portable (unless the issue to be solved is critical).

OK. I did more research into this and it seems that the main issue with Orca is that if focus is within a gridcell but not on the gridcell itself it will not announce the change in column or row.

For example, try with the ARIA grid example:

https://www.w3.org/WAI/ARIA/apg/example-index/grid/dataGrids.html#ex1_label

In the default focus mode, when you reach the Description column, where the focus goes on the link within it, the column header will not be announced. Even though the example is for a role="grid" it demonstrates the same issues that role="table" has.

However, if you manually switch to browse mode (Insert+A on desktop) and use the special Orca table controls (Alt+Shift+ArrowKey) then you get column and row announcement. These are designed for navigating a "static" table, but mostly still work with inputs as well. It at least gives you a clearer idea of the structure, and once you are used to it tabbing in focus mode might make more sense.

However, when testing this with the addressbook table, there is an issue. EDIT: See bug 1776644

In summary

For 102

For 102, I think we should leave it as it is, but maybe address the known issue with the screen-reader-only class. EDIT: See bug 1776644

Despite what I said in the other bug about how we should use a consistent structure, lets only use this table structure for the email addresses for now. There are two main reasons:

• Unlike the other fields, these emails are linked through the "Default" property. So the grouping plays a slightly more relevant role.
• There are possible screen reader issues, and I don't think we should spread them all over the form just yet.

It would be great to have some feedback from more experienced screen reader users, and for different screen readers. Does the table structure help, and would other parts of the form benefit from the same structure?

For future releases

If we can use both header and column labels, that seems to work quite well in both focus mode and browse mode. NOTE: in english, concatenating the row and column headers reads fine, but we might have to allow for more flexibility for labels in other locales.

However, I think we should wait on some user feedback on the email input for this.

For the Orca navigation issue, see bug 1776644