Add missing data

Signed-off-by: Olga Bulat <obulat@gmail.com>

documentation/projects/proposals/rekognition_data/20240510-implementation_plan_machine_generated_tags_frontend.md

@@ -78,13 +78,14 @@ normalized to prevent duplicates.
 The generated tags section should split the tags by different providers into
 subsections, and should use the provider of the tag as the section label. For
 instance, if there are tags by both `recognition` and `clarifai`, there will be
-two sub-sections in the Generated tags section: tags generated by `recognition`
+two subsections in the Generated tags section: tags generated by `recognition`
 and tags generated by `clarifai`. In the future, if there are more providers,
 there could be more tag sections. The tags in each subsection will be ordered by
 their accuracy.
 
 There is no need to create a separate component for machine-generated tags, the
-slot will enable us to display the additional accuracy information.
+slot in the `VTag` component will enable us to display the additional accuracy
+information.
 
 ### Add "About tags" description page
 
@@ -117,11 +118,8 @@ result pages of the Nuxt frontend.
 
 <!-- Describe any alternatives considered and why they were not chosen or recommended. -->
 
-The tags will be displayed in two sections: "Source tags" and "Generated tags".
-
-For the machine-generated tags, we want to add a link to the page that describes
 We have the provider (currently, it will be "clarifai" and "rekognition") and
-the accuracy data for the machine-generated providers.
+the accuracy data for the machine-generated tags.
 
 There are several options of displaying these properties.
 
@@ -131,17 +129,17 @@ There are several options of displaying these properties.
 3. Display generated tags in sections by provider so that we don't duplicate the
    tag provider on each tag. Then, on each tag, display the accuracy.
 
-The first option is the simplest to implement, however, it fails to provide
-the fullest information to the users. The second option provides the accuracy
-and provider information to the user, however it is not very accessible.
-Different browsers and screen readers treat the tooltips differently. We have
-enough room on the page to display this data in full, using the third option:
-labelling all the tags generated by a single provider with a "by provider"
-heading, and adding the accuracy to the tag's inner content. This way, the
-user will see the provider and the accuracy of the tag without any additional
-actions. As a bonus, if a tag is generated by multiple providers, the user
-will see that different providers generate the same tag, and will be able to
-see the difference in accuracy between the providers.
+The first option is the simplest to implement, however, it fails to provide the
+fullest information to the users. The second option provides the accuracy and
+provider information to the user, however it is not very accessible. Different
+browsers and screen readers treat the tooltips differently. We have enough room
+on the page to display this data in full, using the third option: labelling all
+the tags generated by a single provider with a "by provider" heading, and adding
+the accuracy to the tag's inner content. This way, the user will see the
+provider and the accuracy of the tag without any additional actions. As a bonus,
+if a tag is generated by multiple providers, the user will see that different
+providers generate the same tag, and will be able to see the difference in
+accuracy between the providers.
 
 ## Design
 
@@ -157,7 +155,8 @@ provider headings and the accuracy to the tags.
 
 <!-- What hard blockers exist that prevent further work on this project? -->
 
-Since we already have machine-generated tags available in the API, there are no blockers for this work.
+Since we already have machine-generated tags available in the API, there are no
+blockers for this work.
 
 ## Accessibility
 
@@ -169,12 +168,18 @@ understand what the list is for. It is always desirable to have visible label
 next to a list of elements.
 
 The display of generated tags' provider and accuracy is, on the other hand, a
-challenging problem from accessibility standpoint. Tooltips are often described
-as inaccessible for mobile users who do not have a hover action. MDN's section
-on tooltip best practices suggests providing "clear labels and sufficient body
-text" instead of tooltips that hide important information. We could add the tag
-accuracy to the However, if we decide to add the provider to the generated tags,
-there will be a lot of duplication.
+challenging problem from accessibility standpoint. Tooltips proposed in the
+second alternative option are often described as inaccessible for mobile users
+who do not have a hover action. MDN's section on tooltip best practices suggests
+providing "clear labels and sufficient body text" instead of tooltips that hide
+important information.
+
+The third alternative option, where the provider is displayed once per the list
+of all the generated tags generated by it, and accuracy is displayed on the tag
+itself, is the most accessible option. The user will see (or hear) the provider
+and the accuracy of the tag without any additional actions. We need to make sure
+that the tag name and its accuracy are separated (such as with an invisible,
+`sr-only`, dot) to make the screen readers add a pause between them.
 
 ## Rollback
 
@@ -189,11 +194,3 @@ We can roll back this solution by reverting the PRs implementing this.
 The tag headings will be translated as usual. For the "About page" it is
 important to split the text into shorter chunks to make them easier to handle
 for translators. The eslint rule will make sure that this is done properly.
-
-## Risks
-
-<!-- What risks are we taking with this solution? Are there risks that once taken can’t be undone?-->
-
-## Prior art
-
-<!-- Include links to documents and resources that you used when coming up with your solution. Credit people who have contributed to the solution that you wish to acknowledge. -->