Support aria-description #69
Conversation
Co-Authored-By: Carolyn MacLeod <Carolyn_MacLeod@ca.ibm.com>
|
@joanmarie what are the next steps for this one? |
Group review, including from @accdc who is taking the lead on this spec. |
There was a problem hiding this comment.
Shouldn't there also be a change in the algorithm found in https://w3c.github.io/accname/#mapping_additional_nd_te? Compare with what's there for name computation, in particular: 2B addresses name when there is an aria-labelledby. 2C addresses name when there is aria-label.
|
Hi @joanmarie, there should not be a change to the algorithm. When aria-describedby is used, it uses the name algorithm as it stands now to get the text. That algorithm does not consider description markup, it only returns the primary text. When aria-describedby is not used, then aria-description can be used to set the description. However, aria-description does not affect the recursive algorithm, whether it's used for name or description. |
|
Ok.... Though I still think it's odd that the algorithm for computing the name and description lacks any mention of |
As it stands, we have these 3 headings, which is confusing already: IMO the overlap between these names is kind of confusing already. The last one could be renamed "Primary Text for a Subtree Computation". Then the first two would explain that the Primary Text for a Subtree is used for aria-labelledby and aria-describedby. But it doesn't make sense to mention aria-description in that Primary Text Computation, because that would change the way aria-description works, which is not desired. |
|
See also #77 |
joanmarie
requested review from
joanmarie and
carmacleod
and removed request for
joanmarie
|
The ARIA Working Group just discussed The full IRC log of that discussion<carmacleod> TOPIC: aria-description<carmacleod> github: https://github.com//pull/69 <carmacleod> joanie: a bit weird that aria-description is not in Name & Description computation <jamesn> q+ <carmacleod> aaronlev: confusing to have sections names "Name", "Description", and "Name & Description" - need to have a new name, maybe "Primary Text Computation" <carmacleod> ack jamesn <aaronlev> 1. Change third item to be "Primary text computation" <aaronlev> 2. Change description computation to add all the attributes that might be used <aaronlev> 3. Change primary text computation to be modeless in terms of what it's being used for <aaronlev> Item 2 would include add aria-description <aaronlev> ^ my proposal for 13 <aaronlev> ^ my proposal for 1.3 <carmacleod> jamesn: can we add pr-preview to the accname repo? <carmacleod> MichaelC: yes - I'll do that <carmacleod> carmacleod: I think I have a pr for that <MarkMccarthy> s/^ my proposal for 13 <carmacleod> jamesn: need a preview to look at this <MarkMccarthy> s/^ my proposal for 13/ <carmacleod> mck: how about using the name "Text Content Computation"? instead of "Primary..." <carmacleod> aaronlev: I like that name. "Text Content Computation" <carmacleod> aaronlev: how about if I just expand the current pr to add this? <carmacleod> zakim, next item <Zakim> agendum 4. "meter role should have optional aria-valuemin/max with defaults" taken up [from jamesn] <jamesn> https://github.com/w3c/aria/issues/1123 |
|
@aleventhal Notes from the meeting bot:
There was general agreement (not in the notes because the scribe was lagging behind... 😄 ). |
Co-Authored-By: Carolyn MacLeod <Carolyn_MacLeod@ca.ibm.com>
1. Changes "4.3 Name and Description Computation" to "4.3 Text Content Computation", to be reused by the "4.1 Name Computation" and "4.2 Description Computation". 2. Change Text Content Computation to be modeless in terms of what it's being used for, in other words remove phrases like "if computing accessible name". 3. Change description computation to add all the attributes that might be used, in precedence order, and format it in an easy-to-read table.
|
I think this is is a step in the right direction, but doesn't solve everything. In the table, I mention all relevant HTML markup, because currently I think the spec dances around HTML markup, yet seems to desperately want to mention it. HTML should be treated as a first class citizen by this spec, maybe even SVG too. Otherwise it's hard to define an order of markup precedence, let alone which markup should be processed. Getting names and descriptions right in HTML is too important to just hand wave around this. |
|
Hi, I think this is a great step in the right direction. Please merge if you will. We will continue working on the rest as well after. |
|
@aleventhal, many thanks for the comprehensive revision. I think it removes all the ambiguities and errors that were previously contained. In the preview, there is only one problem with the numbering of the list items: instead of letters, numbers are used, so that the references (e.g. "2F.i") no longer work. But maybe this is just a CSS problem of the preview. The table for description is very good. I just think the first column header is wrong (it should be "precedence" instead of "predence", right?) |
|
@accdc I'm not authorized to merge, unfortunately. Do you want to authorize me or merge? |
|
I'm never going to be as good with github as others here, so if you or Melanie could help with this I'd appreciate it. |
|
From call: Dependent on #433? @scottaohara |
Committing some diffs from prior review (with editor's and WG's blessing)
Remove specific references to the unique HTML elements from the table. Replaced these rows with a new row indicating there may be host language features which participating in the description computation, and to look at HTML AAM for the elements which are applicable.
This PR is necessary to fully address the needs of the accName PR - w3c/accname#69 - New language has been added to the introduction of this section, better aligning it with the normative text of accName's new 4.2 section. - cut down item 1 the text was redundant per the new language added to the introduction of the section. - Modified each of the section 2 items to align with the accName table column "how to compute description". - Revised the final item (4) to align with the accName normative text, and the revised introduction of this section, stating that UAs are even expected to return an empty description.
|
Do we intend the aria-description value on an element to be able to be included in its description by a self-reference in the value of aria-describedby? If so, that does not appear to be supported by the current definition of aria-describedby computation. If not, we may want to make that constraint more clear. It would make the behavior of aria-describedby slightly different from the behavior of aria-labelledby. |
I don't think that makes sense. If elements are referenced by aria-describedby, then their AccName is relevant and not their AccDesc. I.e. the AccName of an element becomes the AccDesc of the element which is referred to by aria-describedby. The AccDesc of an element does not matter (whether via title, aria-description or any other method) if the element is referenced via aria-describedby. |
Co-authored-by: James Craig <cookiecrook@users.noreply.github.com>
SHA: 81361ec Reason: push, by MelSumner Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Closes issue #68 and issue #77
Testing whether editing this comment triggers pr-preview.
Yay! It does! 🎉
Editing comment again now to add
#mapping_additional_nd_descriptionin-page anchor for preview.Preview | Diff
Preview | Diff