Is 'total accumulated text' necessary?

[OisinNolan]

At the end of 4.3 there is an instruction to:

Append the result of each step above, with a space, to the total accumulated text.

The definition for total accumulated text is:

The text equivalent computed up to, but not including the current node.

Is it possible for there to be more than one result from this algorithm? It seems like whichever step of the algorithm is applied to the root node will return the final accessible name / description -- any results computed recursively being stored in an accumulated text variable, which ends up being returned as a single result in the end.

I may be missing something here, but if it is the case that the result of the first rule applied is always the total accumulated text, then maybe the spec could be simplified by removing total accumulated text and the instruction to append multiple results?

[accdc]

Hi,
I'm not sure if I'm understanding your logic, because it seems that the spec is basically saying the same thing using different words.

To answer your question, the algorithm is fluid, and there at times may be different results for root that aren't always the same, such as how and when inline or block level elements are applied, if CSS content is present, if the root includes child nodes that are form fields, and so on.

Also, there are 2 different properties that are handled by the algorithm, one is the accessible name, and the second is the accessible description, so when the algorithm computes one or the other, the result will indeed be different depending on which is being computed for root.

If I am misunderstanding, please let me know.

Thanks,
Bryan

[OisinNolan]

Hi Bryan, thanks for your response.

As a preface, the motivation behind this is to simplify the algorithm by removing total accumulated text altogether and using the result as the return value of the algorithm.

I don't think I did a great job wording my previous question, so I'm going to try to reformulate it here:

I am questioning the relevance of the total accumulated text variable. It seems to me that, given some root node as input, the accname algorithm will look at each of the steps from 2.A to 2.I sequentially and apply one of them to the root node in order to calculate its accessible name. It is the language used in steps 2.A to 2.I that implies that only a single step may be applied to a given input node. Each step is of the form 'Otherwise, if X then Y', implying that for some step to be applied to the input node, none of the previous steps have been applied and none of the following steps will be.

If we accept that only one step (2.A - 2.I) may be applied to a given input node, then there must only ever be one result for a given input node (the result of recursive steps being accumulated text). If there is only ever one result from the accname algorithm, then the total accumulated text variable seems unnecessary, as its sole purpose appears to be to concatenate multiple results. I wonder if the result itself may act as the accessible name or description returned by the algorithm.

I would be interested to see any examples of an input node for which multiple steps would be applied, producing multiple results and thus validating the existence of total accumulated text.

[accdc]

Thanks, that does help. :)

It never made a lot of sense to me either, since my background is primarily in object oriented programming languages, and this algorithm implies a single line of processing logic that doesn't really lend itself well to morphing individual steps as needed without having to hack up the wording even more than it already is.

The clarity of the algorithm has been discussed quite a few times in various meetings as well, and we all agree that the layout and step documentation is overly difficult to understand. One of my action items, when I have more time of course, is to greatly simplify the spec text to make it easier to understand, which I still hope to do one day. Someday, that mythical day between Sunday and Monday.

A lot of these became clearer to me after having to translate the spec text into working code, which is where I found many of the grey areas that we need to shore up going forward.

At present though, and in the interest of preventing further delays, I'm going to have to address these things within the context that they already exist. This means having to push steps down with more steps, as well as clarifying those that are, so they can account for new functionality or differing requirements.