desktop-options.html - Issue 29584714: Issue 5874 - Sync strings with the agencies translations

Side by Side Diff: desktop-options.html

Issue 29584714: Issue 5874 - Sync strings with the agencies translations (Closed)

Patch Set: Created Oct. 20, 2017, 9:10 p.m.

Left:
Right:

Use n/p to move between diff chunks; N/P to move between comments.

Jump to:

View unified diff | Download patch

OLD	NEW
1 <!DOCTYPE html>	1 <!DOCTYPE html>

2 <!--	2 <!--

3 - This file is part of Adblock Plus <https://adblockplus.org/>,	3 - This file is part of Adblock Plus <https://adblockplus.org/>,

4 - Copyright (C) 2006-present eyeo GmbH	4 - Copyright (C) 2006-present eyeo GmbH

5 -	5 -

6 - Adblock Plus is free software: you can redistribute it and/or modify	6 - Adblock Plus is free software: you can redistribute it and/or modify

7 - it under the terms of the GNU General Public License version 3 as	7 - it under the terms of the GNU General Public License version 3 as

8 - published by the Free Software Foundation.	8 - published by the Free Software Foundation.

9 -	9 -

10 - Adblock Plus is distributed in the hope that it will be useful,	10 - Adblock Plus is distributed in the hope that it will be useful,

(...skipping 135 matching lines...) Expand 10 before \| Expand all \| Expand 10 after Loading...
146 </ul>	146 </ul>

147 <p class="i18n_options_more_filters_note"></p>	147 <p class="i18n_options_more_filters_note"></p>

148 </div>	148 </div>

149 </section>	149 </section>

150 </div>	150 </div>

151	151

152 <!-- Whitelist tab content -->	152 <!-- Whitelist tab content -->

153 <div id="content-whitelist" role="tabpanel" aria-labelledby="tab-whitelist ">	153 <div id="content-whitelist" role="tabpanel" aria-labelledby="tab-whitelist ">

154 <header>	154 <header>

155 <h1 class="i18n_options_tab_whitelist"></h1>	155 <h1 class="i18n_options_tab_whitelist"></h1>

156 <p class="i18n_options_whitelist_description"></p>	156 <p id="whitelist-description" class="i18n_options_whitelist_descriptio n"></p>

157 </header>	157 </header>

158 <form class="section">	158 <form class="section">

159 <input id="whitelisting-textbox" type="text">	159 <input id="whitelisting-textbox" type="text">

160 <button id="whitelisting-add-button"	160 <button id="whitelisting-add-button"

161 type="submit"	161 type="submit"

162 data-action="add-domain-exception"	162 data-action="add-domain-exception"

163 class="i18n_options_whitelist_add primary" disabled>	163 class="i18n_options_whitelist_add primary" disabled>

164 </button>	164 </button>

165 </form>	165 </form>

166 <ul id="whitelisting-table" class="table list">	166 <ul id="whitelisting-table" class="table list">

(...skipping 71 matching lines...) Expand 10 before \| Expand all \| Expand 10 after Loading...
238 <li role="menuitem">	238 <li role="menuitem">

239 <button class="i18n_options_filterList_updateNow update- subscription" data-action="update-subscription"></button>	239 <button class="i18n_options_filterList_updateNow update- subscription" data-action="update-subscription"></button>

240 </li>	240 </li>

241 <li role="menuitem">	241 <li role="menuitem">

242 <a class="i18n_options_filterList_website website" targe t="_blank"></a>	242 <a class="i18n_options_filterList_website website" targe t="_blank"></a>

243 </li>	243 </li>

244 <li role="menuitem">	244 <li role="menuitem">

245 <a class="i18n_options_filterList_source source" target= "_blank"></a>	245 <a class="i18n_options_filterList_source source" target= "_blank"></a>

246 </li>	246 </li>

247 <li role="menuitem">	247 <li role="menuitem">

248 <button class="i18n_options_filterList_delete delete" da ta-action="remove-subscription"></button>	248 <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 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 Show quoted text On 2017/10/23 12:21:39, ire wrote: > 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. 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 h Show quoted text On 2017/10/23 14:11:08, saroyanm wrote: > On 2017/10/23 12:21:39, ire wrote: > > 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. > > 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. 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. Show quoted text > 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. Ack saroyanm 2017/10/23 16:14:32 Sorry I think I miss communicated here. I mean it Show quoted text On 2017/10/23 15:45:34, ire wrote: > On 2017/10/23 14:11:08, saroyanm wrote: > > On 2017/10/23 12:21:39, ire wrote: > > > 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. > > > > 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. > > 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. > > > 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. > > Ack > 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 Show quoted text On 2017/10/23 16:14:32, saroyanm wrote: > On 2017/10/23 15:45:34, ire wrote: > > On 2017/10/23 14:11:08, saroyanm wrote: > > > On 2017/10/23 12:21:39, ire wrote: > > > > 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. > > > > > > 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. > > > > 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. > > > > > 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. > > > > Ack > > > > 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. 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).
249 </li>	249 </li>

250 </ul>	250 </ul>

251 </div>	251 </div>

252 </div>	252 </div>

253 <button data-action="remove-subscription" class="control delete" ></button>	253 <button data-action="remove-subscription" class="control delete" ></button>

254 </div>	254 </div>

255 </template>	255 </template>

256 </ul>	256 </ul>

257 <div class="side-controls wrap">	257 <div class="side-controls wrap">

258 <button class="i18n_options_filterList_add primary" data-action="ope n-dialog" data-dialog="import"></button>	258 <button class="i18n_options_filterList_add primary" data-action="ope n-dialog" data-dialog="import"></button>

(...skipping 139 matching lines...) Expand 10 before \| Expand all \| Expand 10 after Loading...
398 </div>	398 </div>

399 <!-- Notification -->	399 <!-- Notification -->

400 <div id="notification" aria-hidden="true" aria-live="polite">	400 <div id="notification" aria-hidden="true" aria-live="polite">

401 <strong id="notification-text"></strong>	401 <strong id="notification-text"></strong>

402 <button id="hide-notification" data-action="hide-notification">	402 <button id="hide-notification" data-action="hide-notification">

403 <span class="i18n_options_notification_hide sr-only"></span>	403 <span class="i18n_options_notification_hide sr-only"></span>

404 </button>	404 </button>

405 </div>	405 </div>

406 </body>	406 </body>

407 </html>	407 </html>

OLD	NEW

« no previous file with comments | « no previous file | desktop-options.js » ('j') | no next file with comments »