Closed
Bug 1068883
Opened 10 years ago
Closed 9 years ago
[Camera] Menu items should be given proper accessibility roles
Categories
(Firefox OS Graveyard :: Gaia::Camera, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: eeejay, Assigned: yzen)
References
Details
(Keywords: access, Whiteboard: [b2ga11y p=1])
Attachments
(1 file)
Now they are just distinct text nodes.
Reporter | ||
Updated•10 years ago
|
Whiteboard: [b2ga11y p=1]
Reporter | ||
Updated•10 years ago
|
Component: Gaia → Gaia::Camera
Updated•10 years ago
|
Summary: Menu items should be given proper accessibility roles → [Camera] Menu items should be given proper accessibility roles
Comment 1•10 years ago
|
||
eeejay: We need more info on exactly which part of the UI you are talking about and what accessibility role you require.
Flags: needinfo?(eitan)
Hi Ee jay, I am not sure if what you meant by the accesiblity roles. But is this close to what you needed. I have put the roles on Options Menu and then also on the next level of options menu which you select Cheers, Bhupendra
Attachment #8515626 -
Flags: feedback?(eitan)
Reporter | ||
Comment 3•10 years ago
|
||
Comment on attachment 8515626 [details] [review] pull-request (master) This is definitely the right direction, thanks! There are two issues that need to be resolved before we could call this fixed: 1. The heading (h4,h5) tags in the menu item need to either be removed, or they should be assigned a role of 'presentation'. This is because the screen reader presents these items as headings when they are not. 2. The :before pseudo element has a text content set to the data-icon with a special font. This seems to be the new way of doing icons, i'm honestly not sure how we could make that work well. To clarify, the issue is that the screen reader sees the 'content:' of the pseudoelement and reads it, so you get things like 'self-timer, Self-Time, Off'. Also, I think the menu will only truly be usable once bug 1068880 is resolved. Wilson, NI?ing you back :) Do you have any ideas about how to fix the font-icon issue I mentioned in point 2?
Flags: needinfo?(wilsonpage)
Attachment #8515626 -
Flags: feedback?(eitan)
Comment 4•10 years ago
|
||
(In reply to Eitan Isaacson [:eeejay] from comment #3) > Wilson, NI?ing you back :) Do you have any ideas about how to fix the > font-icon issue I mentioned in point 2? Can we use `aria-hidden="true"`? This may require some adjustment to the markup so that the icon has its own element eg. <i data-icon="tick" aria-hidden="true"></i>
Flags: needinfo?(wilsonpage)
Reporter | ||
Comment 5•10 years ago
|
||
(In reply to Wilson Page [:wilsonpage] from comment #4) > (In reply to Eitan Isaacson [:eeejay] from comment #3) > > Wilson, NI?ing you back :) Do you have any ideas about how to fix the > > font-icon issue I mentioned in point 2? > > Can we use `aria-hidden="true"`? This may require some adjustment to the > markup so that the icon has its own element eg. <i data-icon="tick" > aria-hidden="true"></i> Yes, that would work. Less elegant, but effective.
Flags: needinfo?(eitan)
Wilson & Ee jay Thanks for your comments. I have fixed point number one. Point number 2 i do understand what is the implication , but because i dont have a FireFOx Phone i am not able to locate those elements. Would you be able to tell me where these are. Then i can bring this Bug to logical end.
Flags: needinfo?(wilsonpage)
Comment 7•10 years ago
|
||
Bhupendra: It's going to be quite tricky for you to do this without a phone as AFAIK Camera app won't run on Simulators. I could amend you patch from here, or if you're near the office you could pop in one day :) In summary: You need to make sure data-icon attributes have their own elements. So in the case of the settings list, each setting's markup should look roughly like: <li><i data-icon="icon-name" aria-hidden="true"></i> ... </li> instead of: <li data-icon="icon-name"> ... </li> This applies to settings.js and setting-options.js views.
Flags: needinfo?(wilsonpage)
Assignee | ||
Updated•9 years ago
|
Assignee: nobody → yzenevich
Status: NEW → ASSIGNED
Assignee | ||
Comment 8•9 years ago
|
||
fixed with bug 1068880
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•