Delete buttons in edit mode are not accessible

NEW
Assigned to

Status

Firefox OS
Gaia::Components
3 years ago
3 years ago

People

(Reporter: eeejay, Assigned: Takeshi Kurosawa)

Tracking

(Blocks: 1 bug, {access})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [b2ga11y p=1])

Attachments

(1 attachment)

(Reporter)

Description

3 years ago
The little x icons are not accessible to the screen reader.

Comment 1

3 years ago
the problem here is that the remove button are just an empty span so I think it just nead an aria-label type "remove this app". Is it ok for you ?
Flags: needinfo?(eitan)
(Reporter)

Comment 2

3 years ago
That is the general solution, yes. You will need to test it with the screen reader to see that it works correctly.
Flags: needinfo?(eitan)

Comment 3

3 years ago
ok the problem is that I don't see how to access this screen on the simulator with the screen reader on because I can't use the home button
Flags: needinfo?(eitan)
(Reporter)

Comment 4

3 years ago
Sorry for the late reply..

I think the simulator home button has been fixed in bug 1097814, is it still an issue?
Flags: needinfo?(eitan) → needinfo?(aurelien.levy)

Comment 5

3 years ago
How can I get this version of the simulator ? and I'm not sure I found the good file to change, is it Result.js ?
Flags: needinfo?(aurelien.levy) → needinfo?(eitan)
(Reporter)

Comment 6

3 years ago
Sorry, you don't need the home button for this. My mistake.

This bug is actually not simple to resolve. A few things need to happen:
1. The delete <span class="remove"> needs a role of button, and a label in the form of "delete [app name]".
2. The delete button can't be a child of a role="link", so the entire structure of the app icons perhaps needs to change:
  (a) The icon div, should have a role of "group" or maybe "presentation".
  (b) The child p, should get a role of "link", also, instead of using margin-top to position itself below the icon, it should use padding-top, in order to have the <p> take up all the space of the icon.

If the above is done correctly, when in edit mode the remove buttons will be accessible in the screen reader, have the correct label, and work.

I am pretty sure the changes here need to happen in the gaia-grid component. So I am changing the bugzilla component.

This is probably not a good first, second or third bug :) If you want to take it anyway, let me know and we could discuss it further.

I could point you towards good bugs to start with:
https://bugzilla.mozilla.org/buglist.cgi?f1=blocked&list_id=11720019&o1=substring&resolution=---&status_whiteboard_type=allwordssubstr&query_format=advanced&status_whiteboard=%5Bgood%20first%20bug%5D&v1=893789
Component: Gaia::Homescreen → Gaia::Components
Flags: needinfo?(eitan)

Comment 7

3 years ago
I'm not sure we need to do all this changes because in edit mode all the link trigger the remove action. So if we just add the aria label on the span the link will become something like : "xxx remove"
Flags: needinfo?(eitan)
(Reporter)

Comment 8

3 years ago
(In reply to aurelien levy from comment #7)
> I'm not sure we need to do all this changes because in edit mode all the
> link trigger the remove action. So if we just add the aria label on the span
> the link will become something like : "xxx remove"

Actually, the "link" could be used for dragging the the icon and putting it in a different order, that would be a different bug though.
Flags: needinfo?(eitan)

Comment 9

3 years ago
maybe the aria-label can be something like : "double tap to remove or drag to change the order" but I don't know how accessible is the drag and drop mechanism
Flags: needinfo?(eitan)
(Reporter)

Comment 10

3 years ago
The aria label should not have screen reader instructions. Simply "remove [app label]" is good enough.

Also, I just double checked, and the link does not trigger the remove action. So depending on what the user is focusing, they will have different actions (either remove or drag-to-reorder).

The drag and drop work should happen in another bug.
Flags: needinfo?(eitan)
(Assignee)

Comment 11

3 years ago
I'm planning to write patch at the weekend. I wonder if anyone is working or will work on it so that I will try another bug.

Comment 12

3 years ago
I prefer to tell you that you can go with it because i'm not sure to found the time to work on it this week

Comment 13

3 years ago
Created attachment 8557448 [details] [review]
[PullReq] takenspc:bug1069607 to mozilla-b2g:master
(Assignee)

Updated

3 years ago
Attachment #8557448 - Flags: review?(chrislord.net)
(Assignee)

Updated

3 years ago
Assignee: nobody → taken.spc
Comment on attachment 8557448 [details] [review]
[PullReq] takenspc:bug1069607 to mozilla-b2g:master

The method looks sound, but actually trying it out, icons now have a semi-transparent rectangular background when being tapped/dragged, which is obviously not intended. I assume this is just a styling issue introduced by using button instead of div - re-flag me when you think this is fixed.
Attachment #8557448 - Flags: review?(chrislord.net) → feedback+
You need to log in before you can comment on or make changes to this bug.