Textview not accessible to UI tests about phfcomposebarview HOT 8 CLOSED

Ah, it looks like the iOS Accessibility Programming Guide explains (inc. sample code) how to make the contents of custom container views accessible. Unfortunately we don't have any Obj-C expertise in-house to try out this implementation.

from phfcomposebarview.

Hey @jamesbebbington. Sorry, but I don't have the capacity to implement this change.

from phfcomposebarview.

Hey @jamesbebbington, I've looked a bit into this and the UIAccessibilityContainer protocol. I changed the container that contains the text view from a button to a normal view. Would you mind testing with the improve-accessibility branch, specifically this commit? 28a3b5c

Thanks!

from phfcomposebarview.

Thanks @fphilipe, much appreciated.

UI tests can now address the text view, however I'm seeing some strange behaviour when programatically entering text. Given this UI Test case:

import XCTest

class PHFComposeBarViewExampleUITests: XCTestCase {

    override func setUp() {
        super.setUp()
        continueAfterFailure = false
    }

    func testComposeBar() {
        let app = XCUIApplication()
        app.launch()

        app.staticTexts["PHFComposeBarPlaceholderLabel"].tap()
        app.textViews["PHFComposeBarTextView"].typeText("Here is some sample text. It's a few lines long but not too long. I think that should do it.")
        app.buttons["PHFComposeBarUtilityButton"].tap()
        sleep(5)
    }

}

the entered text is being partially erased as it's entered:

Oh and a default accessibility identifier for the placeholder label would be helpful, so it's easier to address in tests when the app is localised.

EDIT: I forgot that I had set the accessibility identifiers in the the example app. Test code above updated and pushed in new ui-tests-2 branch.

Thanks!

from phfcomposebarview.

I've pushed a couple of updates to the ui-tests-2 branch, fixing the misnamed buttons and adding a (failing) assert that checks that the entered message was properly saved.

from phfcomposebarview.

@jamesbebbington thanks! I've added a commit introducing a test (based on yours). I was not able to reproduce your erasing text problem you showed in the GIF.

I'm wondering if the accessibility identifiers should be set directly in PHFComposeBarView or if it should be up to the consumer of it to set it (as you did and I've taken over).

From my side this would be ready. Let me know if this works for you.

from phfcomposebarview.

Cheers @fphilipe, will take a look now.

I'm wondering if the accessibility identifiers should be set directly in PHFComposeBarView or if it should be up to the consumer of it to set it (as you did and I've taken over).

I don't think it matters too much either way, as long as consumers can set them. I think it's probably fine to leave them unset, as I'd imagine anyone who wanted to use them would want to rename them anyway.

from phfcomposebarview.

I was not able to reproduce your erasing text problem you showed in the GIF.

Yeah, it's an odd one, it seems a bit intermittent.

I integrated the improve-accessibility branch into our app and ran tests on iPhone 4s, 5, 6 & 6 Plus across four different languages and they were all fine, so not really sure what's going on with that.

Let me know if this works for you.

Yup, many thanks @fphilipe!

from phfcomposebarview.