-
Notifications
You must be signed in to change notification settings - Fork 382
Feed Display Example Broken Star Images #2628
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
The "correct" path for the star images, btw, is e.g. https://www.w3.org/WAI/content-assets/wai-aria-practices/patterns/feed/examples/imgs/rating-4.png Hopefully that's not a "yeah, we already knew that" sort of thing, but thought I'd throw it out there. |
Hi @frozenzia, Thank you for the PR. Per Howard's comment, I am going to close that PR. However, I am wondering if you would be willing to work on the solution proposed at the top of this issue, which is to change the example code to use inline SVG for the ratings stars? |
@mcking65, I don't want to make any promises, but I'm definitely interested in giving it a shot. As I just mentioned elsewhere, though, I'm not very experienced with contributing to projects - may need a bit of hand-holding or at least don't be surprised if I end up asking "dumb" questions along the way. |
@mcking65, hey, sure, sign me up for this issue. If I've understood things properly, the next step here will be that "An editor will confirm there are no conflicting plans and, if needed, provide guidance." |
@frozenzia wrote:
OK, super! As editor, I can confirm there are no conflicting plans, and this is a good time to move forward with a PR for this issue. The proposed solution that the Task Force is landed on is to use inline SVG for the rating star images. You might take inspiration from content/patterns/radio/examples/radio-rating.html. |
The APG Task Force is working to encourage contributions from the larger community. So, please don't hesitate to ask any questions. We will do our best to provide helpful guidance. |
@mcking65, ok, having looked at this a VERY little bit, I have questions/problems...
Having a quick look at one of the failed tests, I see
So that's basically where we are -- stopped dead before reaching the starting line. Any advice / tips / ideas / links to info are greatly appreciated. TIA! |
Alright, had a chance to do some more looking, and have an interesting finding. 1st test that failed for me was While digging around looking at some As far as I can tell, there is no visible change or indication anywhere which would tell what sort of "way" is currently being used, BUT, hitting Naturally, though, when I then bothered to try the test with Safari, it showed the same erroneous focusing that Firefox had previously. |
Yes, please ask questions of this nature here in GitHub. No need for a mention unless you are responding to a specific person. I am curious to know if others developing on macOS have these same problems running the tests. @jongund do you see the issues that @frozenzia describes here? I have to admit that I've had so many challenges with my Windows environment that I don't run the tests locally. I commit with the -n option and push to a remote branch for which I have created a draft PR. Then, I look at the test results from the remote run. Not efficient, but I'm so used to my workaround that I probably don't even realize how much time I'm losing over it. It's less of a hit for me because I rarely touch the js or css. |
My first thought is to write "determineControlKey", which somehow checks platform and if Mac returns Key.COMMAND, otherwise Key.CONTROL. Then replace all references to Key.CONTROL with a call to determineControlKey. Not imm. figuring out how to get that platform info, however. Looks like window.navigator.platform wld be the (albeit deprecated) way, but can't get window w/Selenium Webdriver? An easy workaround cld be to flip Control and Command on my Mac in settings before trying to run tests. But on that topic of the tests, I'm ASSUMING that running tests on the main branch will have all tests passing (except those which are intended to fail), but is that a faulty assumption? |
Thinking about this more, I'm not sure why tests would pass if you swap command for control. The js is not listening for command, which is meta, it is specifically listening for control. We don't have any key assignments in the examples that use the meta key. We have an open issue related to the fact that some patterns should have different keys assigned for macOS. For example, in some cases, home should be ctrl+up if using a mac. in edit fields, home should be replaced with cmd-left. We haven't written the patterns or scripts that way ... yet. |
The ARIA Authoring Practices (APG) Task Force just discussed The full IRC log of that discussion<jugglinmike> subtopic: Feed Display Example Broken Star Images<jugglinmike> github: https://github.com//issues/2628 <jugglinmike> Matt_King: Paul Brown (GitHub handle "frozenzia") has volunteered to take this up, but they're having trouble running the tests on their Mac <jugglinmike> andrea_cardona: I develop on a Mac. I can try to run these tests and comment on this issue about my experience <jugglinmike> Matt_King: It appears as though there might be some documentation missing for folks who want to run the tests on Mac. The "command" versus "control" thing may be a red herring <jugglinmike> jugglinmike: I can bring this to Carmen and see that someone from Bocoup takes a look at this alongside andrea_cardona |
@mcking65 , well, I certainly can't claim to 100% understand how the tests are working, but for instance there's a test where we simulate being in a text area and send "ctrl"+a to select all. If I try to pull that off by hand, ctrl+a does nothing as I recall, whereas command+a does exactly what is expected. |
🤔 Wondering about this now I re-read it. My own interpretation of things is that e.g. in this text area box in GitHub, if I send But maybe I'm missing the forest for the trees or something. Totally possible. |
....and by the way, |
Alright. Referring to the recent IRC discussion, yes, I think actually @mcking65 is right, and the "command" vs. "control" thing is a red herring. Sheesh. I honestly cannot fathom how I've managed to mess up doing this testing. I would swear that I've gone thru the failing tests, tried to do them by hand, and CTRL did nothing, but CMD did something. Now I've gone back, double-checked things, and sure enough, CTRL seems to be working just fine in most cases. HOWEVER. In
|
If I DON'T add those 2 lines in the toolbar test, I actually end up with 5 tests failed:
|
Of the 2 tests that are still failing for me (combobox_grid-combo "popup-key-home" and menu-button_actions-active-descendant "menu-end"), popup-key-home at least works for me by hand, so not sure what the issue is there. The 2nd one works by hand as well, but it does seem to me that there is a mistake in the test, albeit one that doesn't actually affect the outcome. The second part of the test, according to the comment, intends to "Send END to the menu while aria-activedescendant is the second item", but based on the keys sent, that only places the focus on the 1st item after the 1st part of the test has succeeded. Unless I'm missing something and there actually is a "before" bit I'm not understanding. But again, this works by hand according the test as written, OR as intended. |
....and of course the added lines break automatic tests, possibly because they're prefixed by "await" (vs. alertdialog test), and Key.COMMAND doesn't return properly / at all in non-mac environment...? Removing the lines and using the same workaround that @mcking65 mentioned -- just letting the draft PR do the work for me. Annoying. |
You are right that in an edit field where the keyboard commands are managed by the browser, they are platform and even potentially browser dependent. So, I used your comments to raise #2735. |
There are broken links in the feed example on the dedicated display page: there should be images representing the number of stars each restaurant has received.
We discussed the issue in the task force and we think the issue is caused by the fact that the links to the images are generated by JavaScript, and we think a good course of action would be to use an inline SVG instead of an external link.
The text was updated successfully, but these errors were encountered: