Issue 5874 - Sync strings with the agencies translations

desktop-options.html

Index: desktop-options.html
===================================================================
--- a/desktop-options.html
+++ b/desktop-options.html
@@ -153,7 +153,7 @@
       <div id="content-whitelist" role="tabpanel" aria-labelledby="tab-whitelist">
         <header>
           <h1 class="i18n_options_tab_whitelist"></h1>
-          <p class="i18n_options_whitelist_description"></p>
+          <p id="whitelist-description" class="i18n_options_whitelist_description"></p>
         </header>
         <form class="section">
           <input id="whitelisting-textbox" type="text">
@@ -245,7 +245,7 @@
                         <a class="i18n_options_filterList_source source" target="_blank"></a>
                       </li>
                       <li role="menuitem">
-                        <button class="i18n_options_filterList_delete delete" data-action="remove-subscription"></button>
+                        <button class="i18n_options_control_remove_title delete" data-action="remove-subscription"></button>

[ire, 2017/10/23 12:21:39]

Should this also have the "title" attribute?

Also (I assume you will handle this in another issue, but I'm not currently
aware if you have created an issue for this yet), most of these buttons don't
have an accessible label.

[saroyanm, 2017/10/23 14:11:08]

Not sure if it's required, we clearly communicate what the button suppose to do
in the text which is "remove".
So when user with screen reader focus the item the person will hear something
along the lines 'Menu item with 4 items selected "remove"' providing titles will
require translating them as well, I do agree that we need to communicate on
icons, but I don't think we need to make explicit menu items having title
attribute.

We do use "title" already for the "trach" icons, but the problem is that they
are not yet translated AFAIK, which still needs to be fixed.

[ire, 2017/10/23 15:45:34]

An accessible label is required, even if it does have the title attribute
(that's a different kind of label). You can provide it via an an aria-label if
you don't want the textcontent in the actual button, but it's definitely a
(really important) requirement. 
Ack

[saroyanm, 2017/10/23 16:14:32]

Sorry I think I miss communicated here. 
I mean it's already accessible and screen readers recognize the button and the
text inside (according to my tests).
I think aria-label needs to be used when the text is not available
https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniqu...

So no need to use additional accessible Technics when using
<button>Remove</button> IMO.

Regarding usage of title vs aria-label on other elements that are lacking text,
I think we might need to test the browsers/user-agents that don't make title
accessible yet, during the implementation I think I tested with Chrome and
screen readers were recognizing the title fine, but didn't tested with other
browsers though.

It feels more like a fault of the browsers rather than "title" attribute being
non accessible, I think this is something that might change in future, but let
me know if I'm wrong and there is another reason of using aria-label in addition
to title instead.

[ire, 2017/10/24 07:36:07]

No worries, I think I misunderstood what you were saying :)

You're absolutely correct that an aria-label is not needed if the text is
actually within the button (<button>Remove</button>)

What I was saying was that, for some buttons on this page, there is no text
content within the actual button. Instead, there is *only* a title attribute.

The accessible name for a control is not supposed to be the title attribute.
That attribute is for something totally different. The accessible name of a
control element like a button has to either come from a <label>, an
`aria-label`, or the actual text content of the element (see
https://developer.paciellogroup.com/blog/2017/04/what-is-an-accessible-name/)

So the fact that browsers don't use the title attribute is not actually a fault
of them. They aren't supposed to use it as the accessible name for the control.

If you run an accessibility test on the page (you can use Lighthouse under the
Audits tab in Chrome), you'll see that the controls raise an error because the
label is missing (even for those with a title attribute).

                       </li>
                     </ul>
                   </div>